-install psm and netscape 6 as yourself or as root. -login as someone else, and run netscape 6.0 as this user , using the netscape6 of the user. -netscape 6.0 will launch but psm does not work. You cannot do any SSL or even open the SA.

This problem comes from creation of xpti.dat and xptitemp.dat in psm/components directory owned by root. The creation of them is not follow the UNIX permission scheme. This problem appears both of mozilla-M17 and netscape v6PR2 on Linux.

*** Bug 50491 has been marked as a duplicate of this bug. ***

David, this seems to be lower priority to me. Marking [nsbeta3+] to take it off the untriaged list, but setting priority to 4 to indicate that this is lower priority.

See also bug 32188 and bug 36007. Fixing 32188 could fix this one and the other one possibly. Although the RSA patent expiring make all these bugs moot when PSM is integrated.

This bug should be fixed with the latest PSM xpi file.

Reopening. 1.) Install the 9/20 netscape-i686-pc-linux-gnu-installer.tar.gz build as root. 2.) Login as another user and start netscape. What happens: I cannot reach an https site, and psm never starts up. Also component.reg is owned by root and is read only.

leaf, I think this can be solved if we pre-generate the component.reg file for PSM. 1 question directly for you: How can we do that? Another question: Can we get PDT to review this bug? This is a major bug that IMHO must be fixed for PR3.

does psm have it's own component registration? that is, does there need to be a components/psm/component.reg? If so, we have to hack the build automation (the stuff that builds psm) to either run psm once to generate this file, or run regxpcom (which is what we use to generate mozilla's component.reg).

per PDT: P3-P5 priority bugs changed from nsbeta3+ to nsbeta3- since we have more important work to do for Seamonkey. If you disagree, please state your case in the bug report and nominate for rtm. Thanks. Perhaps we need to release note this? Is this bug prioritized correctly?

Definately relnote. As for rtm if this is just a mess due to component.reg and if we end up bundling psm then I think this would be fixed by rtm. If we don't then either this is eaily fixed in which case it should get rtm or it isn't in which case it should get relnotertm+arch. leaf or ddrinan?

I think this bug is underated. The current fix (make the directory world writeable) could be viewed as a security hole and anyone who tries to use hotmail will encounter this bug...

Underrated is something of an understatement. I couldn't deploy this in a multi-user environment with a world-writable directory, at least not in good conscience.

I made a post in .security about how to work around this problem. It should help people in the mean time.

Deja news link to blizzard's post http://x63.deja.com/[ST_rn=fs]/threadmsg_ct.xp?thitnum=1&AN=681062626.1&mhitnum=0&CONTEXT=971793682.243859504 Does anyone have a precompiled version of psm with this fix in it?

*** Bug 58287 has been marked as a duplicate of this bug. ***

rtm

*** Bug 53598 has been marked as a duplicate of this bug. ***

*** Bug 59516 has been marked as a duplicate of this bug. ***

Joel Becker (jlbec@evilplan.org) reports that the application hangs when run as a different user.

*** Bug 59516 has been marked as a duplicate of this bug. ***

This is a Bad Bug (TM). There have been complaints about this on the newsgroups, and I can easily reproduce the freeze in our NS6.0 installation: 1. Run netscape as a regular user 2. Load https://www.verisign.com -> throbber activates, but nothing else happens 3. Click the Stop button -> freeze It seems to be a deadlock between CMT_EstablishControlConnection () in thread 3 and PR_EnterMonitor () in thread 2. Stack traces follow as attachments. OS->Linux (because that's a supported OS), Severity->critical, crash keyword. Nominating for moz0.9.

*** Bug 60792 has been marked as a duplicate of this bug. ***

*** Bug 61102 has been marked as a duplicate of this bug. ***

*** Bug 61276 has been marked as a duplicate of this bug. ***

*** Bug 61600 has been marked as a duplicate of this bug. ***

*** Bug 62257 has been marked as a duplicate of this bug. ***

Excerpt of "workaround" (attached above): Make the psm install dir writeable for all users. Not that elegant (but it would surely work).

Ben, unless I gravely misunderstand what goes in the psm directory, that workaround opens the door to any user tampering with the PSM components. This is software that may handle e.g. financially important or confidential data, after all. The workaround is dangerous, makes SSL effectively completely insecure against local users, and is not suitable for anything but single-user, standalone, workstations.

> The workaround is dangerous That's what I tried to say, yes. It wasn't my proposal.

Ok, how about a really silly variation on workaround. peruser psm. admin installs psm. makes it readonly for all relevant users, and then moves it to psm.bin/ Then the admin creates a symlink from psm to ~/mozilla/plugins/psm then the admin creates a shell script or something that creates ~/mozilla/plugins/psm and performs magic on psm.bin/ and that directory. We had an old script that did something similar for entire distributions. I'm sure someone still has it. Recommended magic: mirroring directory structure and symlinking each file in the directory structure.

I'm not sure whether Timeless' solution will work if multiple users are running mozilla on the same machine at the same time (as happens here)...

Forgive me for asking this question, as I don't have all the internals knowledge required to know this on my own, but it would seem to me that the normal solution applies. All the executable/generic bits go in the psm dir, and the user's database/prefs go in ~/.mozilla/psm. Is there a major problem with such a solution?

Sitsofe Wheeler: please try. It should. if it doesn't then we have another serious bug separate from this one. Joel Becker: http://lxr.mozilla.org/mozilla/source/security/psm/ has all of the internals. I can't speak for the authors, but as is PSM does not do what is required to be well behaved, and therefore, we have this bug. I recommend that we use this bug to discuss workarounds and that people file specific bugs for the specific problems.

I thought, we had a workaround - blizzard's Jedimindtrick - not?

The problem was in the followin function: http://lxr.mozilla.org/mozilla/source/security/psm/lib/nlslayer/nlslayer.cpp#69 When starting up, PSM always called nsComponentManager::AutoRegister which tried to create the components.reg file. I'm working on getting PSM into Linux nightlies, which will build the new version of nlslayer.cpp at which point this bug should go away.

*** Bug 63356 has been marked as a duplicate of this bug. ***

Congratulations to the Netscrap managers who have pushed out Netscape 6. You have have made a bad joke of Netscape and the Mozilla project. I hope that Microsoft will release Internet Explorer for Un*x soon; a world writeable psm installation is worse security nightmare than ActiveX!

*** Bug 64131 has been marked as a duplicate of this bug. ***

This should work now that PSM shares the components registry with mozilla. Please re-open if that's not the case.

The Install routine from Debug menu still doesn't work on linux trunk build 2001010821. Is that supposed to work? I'm asking because i have a growing hunch that the real testing is being done on PSM 1.4 and maybe some commerical mozilla build not publically available. The bugs i've "suffered" from regarding PSM are as alive today as they ever were. (like bug 56366).

Here is a build of mozilla with psm built in, and it works. Nightly builds of mozilla on www.mozilla.org presently are missing psm due to build problems. www.concentric.net/~unruh/mozilla-i686-pc-linux-gnu.tar.gz

nightly builds should now include psm [which is newer than the psm from debug>install psm]

PSM now gets built as part of the daily builds for Mozilla. If you use a version from one of the daily builds, this will not be a problem. You shouldn't have to do a separate download anymore either. (I believe there are already bugs open for packaging problems, but I don't remember them off the top of my head.)

well yes... the installation happened, and very quick, so something was in the 2001010821 build that wasn't there before. It's just that PSM hangs when used as normal user. (I installed as root) So the old problem persists, and mozilla freezes when i click "stop" button, and has to be killed. Will d/l the one pointed to here and test.

downloading mozilla-i686-pc-linux-gnu-sea.tar.gz from the lates dir (2001010908) and then used debug/install as root, to install it. Found this: PSM is installed. It happens way quicker than usual - in seconds rather than the usual 30 minutes (i use a modem) - meaning the PSM stuff is bundled in the downloaded tar.gz and not downloaded via web. When i afterwards start moz as normal user, and go to a https site, PSM does NOT start. Never spawns a single thread. mozilla-bin just hangs there, browser window spinning... end of story. If I then click stop, mozilla will freeze and has to be killed. I tried this at two different sites with same result. This bugs summary reads: "psm does not work, when run as a different user in unix. (causes hang/freeze)" That is still the situation. It is not fixed. This is how the file attributes look - are they correct? It is unusual that .so files arent executable, like here, but they may be that packaging problem Javier refer to, since they are all older versions of .so files already present AND exectuable in other browser directories: ls -la /usr/local/mozilla/psm -rw-r--r-- 1 root root 125976 Sep 22 11:29 libz.so -rw-r--r-- 1 root root 952970 Sep 22 16:02 libxpcom.so -rw-r--r-- 1 root root 9285 Sep 22 16:02 libplds4.so -rw-r--r-- 1 root root 15980 Sep 22 16:02 libplc4.so -rwxrwxr-x 1 root root 1555 Sep 22 16:03 start-psm -rwxr-xr-x 1 root root 1324981 Sep 22 16:03 psm -rw-r--r-- 1 root root 211976 Sep 22 16:03 libnspr4.so -rw-r--r-- 1 root root 123270 Sep 22 16:04 component.reg drwxr-xr-x 4 root root 4096 Jan 9 13:47 psmdata drwxrwxr-x 10 root root 4096 Jan 9 13:47 .. drwxr-xr-x 2 root root 4096 Jan 9 13:47 components drwxr-xr-x 4 root root 4096 Jan 9 13:47 . ls -la /usr/local/mozilla/psm/components drwxr-xr-x 2 root root 4096 Jan 9 13:47 . drwxr-xr-x 4 root root 4096 Jan 9 13:47 .. -rw-rw-rw- 1 root root 923891 Sep 22 16:04 libnecko.so -rw-rw-rw- 1 root root 124553 Sep 22 16:04 libnslocale.so -rw-rw-rw- 1 root root 65416 Sep 22 16:04 libstrres.so -rw-rw-rw- 1 root root 152343 Sep 22 16:04 libuconv.so -rw-rw-rw- 1 root root 231634 Sep 22 16:04 libucvlatin.so -rw-rw-rw- 1 root root 73081 Sep 22 16:04 libunicharutil.so -rw-rw-rw- 1 root root 108 Sep 22 16:04 xpti.dat -rw-rw-rw- 1 root root 108 Jan 9 14:08 xptitemp.dat

might add: Downloading junruh's build and using moz as the user i installed as, works OK. The psm directory structure is different in that build btw... ie. it IS no directory - psm and start-psm reside directly in the package dir, not in a subdir called psm.

dark@c2i.net: With the build you downloaded, which is now available at http://ftp.mozilla.org/pub/mozilla/nightly/latest/mozilla-i686-pc-linux-gnu.tar. gz, don't go to iPlanet and download PSM, it already comes with the mozilla build now. The PSM from the iPlanet download site does not work with the latest nightly builds. Please delete your last installation and reinstall the build of mozilla that you downloaded.

I am using an installed build, as run by running ./mozilla-installer provided in mozilla-i686-pc-linux-gnu-sea.tar.gz Once that is installed, there IS no psm executable nor psm dir. Is it hidden in some chrome, waiting to be lured out somehow? In that case: how? I deleted/reinstalled and now i just get "connection refused" when trying to go to https sites, both as root and normal user.

sorry: Meant to ask if it's lurking in some jar file but not unpacked by default? It has gotta be there somehow - it used to take 30 minutes downloading it when i ran Debug/Install PSM. Now it would take seconds, so it unpacks from local disk somehow. But how to i force this to happen?

dark@c2i.net: You are not supposed to do "Debug/Install PSM" any more. It should just work "out of the box". The build comments for the Jan 5th nightly say that the .tar.gz has PSM built-in, and when I downloaded that build, unpacked that as a regular user (not as root), and then ran it as that same user, https sites were loading fine without any further action.

Can someone please tell whether the installer-builds are supposed to contain PSM?

Yes it will work as soon as the bug 64649 is fixed.

the tar.gz, non-installer packages have psm included. as the previous comment alludes, the installer needs to be fixed before installer builds have psm.

Verified fixed with the nightly linux build. http://ftp.mozilla.org/pub/mozilla/nightly/latest/mozilla-i686-pc-linux-gnu.tar. gz

*** Bug 36007 has been marked as a duplicate of this bug. ***

Mass changing Security:Crypto to PSM

Mass changing Security:Crypto to PSM