Last Comment Bug 52653 - regxpcom creates .mozilla in Real User's home
: regxpcom creates .mozilla in Real User's home
Status: RESOLVED INVALID
: relnote
Product: Core
Classification: Components
Component: XPCOM (show other bugs)
: Trunk
: x86 All
: P3 major with 1 vote (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
:
Mentors:
: 57644 145060 198863 (view as bug list)
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2000-09-14 10:52 PDT by Frank Belew
Modified: 2009-07-24 12:11 PDT (History)
15 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
Only ensure/create ~/.mozilla or equiv when looking for user registry (1.93 KB, patch)
2000-10-18 16:12 PDT, Mike Shaver (:shaver -- probably not reading bugmail closely)
no flags Details | Diff | Splinter Review
change nsAppFileLocationProvider::GetProductDirectory to return what the directory would be without forcing it to exist (669 bytes, patch)
2003-03-06 15:03 PST, timeless
no flags Details | Diff | Splinter Review

Description Frank Belew 2000-09-14 10:52:57 PDT
If I use sudo to run regxpcom, it creates the .mozilla dir with permissions of
2700 owner root, and normal group, in the normal users home dir
This prevents me from using sudo, or another 'fake' root shell to install and
register the components

BuildID: (compiled from source) 2000091317
Comment 1 Luis Villa 2000-09-27 09:05:23 PDT
frb: what sudo are you using (RH, Debian, etc?) In most cases (I believe that
this is the RH default, not sure for Debian), sudo does not change the value of
$HOME, which is probably why you are seeing the behavior you are seeing. If
$HOME is set to /root/, and mozilla still installs in /home/$USER, then there is
a problem with mozilla. Otherwise, it is probably a problem with your setup- you
need to obtain root in some way that changes $HOME, or change $HOME manually and
then install mozilla.
Comment 2 Luis Villa 2000-10-18 15:09:09 PDT
frb: are you still seeing this error? I'm going to close the bug out as INVALID
if not. Please post back to the bug and let us know.
Comment 3 Frank Belew 2000-10-18 15:44:39 PDT
I changed my script to create directory and set HOME to it, so I don't know if
the offending code is still in regxpcom

Comment 4 Mike Shaver (:shaver -- probably not reading bugmail closely) 2000-10-18 16:05:24 PDT
This is because of the Special Magic at
http://lxr.mozilla.org/seamonkey/source/xpcom/components/nsRegistry.cpp#456
which we should really tear out.

XPCOM might well be used by people that don't want to muck with .mozilla, so I
think we should only be creating that directory if the application is
specifically asking for the per-user registry.

scc, what say you?  I can whip up a patch.
 
Comment 5 Mike Shaver (:shaver -- probably not reading bugmail closely) 2000-10-18 16:12:28 PDT
Created attachment 17482 [details] [diff] [review]
Only ensure/create ~/.mozilla or equiv when looking for user registry
Comment 6 timeless 2000-10-18 16:32:29 PDT
adding keywords,
relnote: if you run an app that gives you admin priveleges please see this bug 
to understand what to do. [I'm not quite clear on whether doing is setting 
$HOME or preventing a setting, or resetting or doing something else].

pdt: this bug would be low risk, but probably should not be plussed until after 
it is checked into trunk. [And you probably won't plus it, that's fine]
Comment 7 (not reading, please use seth@sspitzer.org instead) 2000-10-19 21:32:31 PDT
adding the people involved who might replace running "netscape -installer" with
"regxpcom && regchrome"
Comment 8 (not reading, please use seth@sspitzer.org instead) 2000-10-23 13:44:15 PDT
*** Bug 57644 has been marked as a duplicate of this bug. ***
Comment 9 (not reading, please use seth@sspitzer.org instead) 2000-10-23 13:45:03 PDT
adding ray, who owned the dup.
Comment 10 Daniel Veditz [:dveditz] 2000-10-23 14:23:29 PDT
r=dveditz on Shaver's patch. It's quite safe, just changes the timing on when 
some existing code is executed so that it's run by the application when 
needed, but not by applications that simply embed XPCOM.

scc: is it possible to get this in? Having .mozilla created by root can't be 
good :-)
Comment 11 selmer (gone) 2000-10-29 08:56:55 PST
The PDT doesn't even see your comments until this gets reviews and moves to rtm+
state.  Since the patch exists, you could get reviews and move to rtm+ rather
easily.  Is the attached patch the smallest, lowest risk fix possible?  Please
include a description of the testing done before moving to rtm+.

Is there any actual usage of this tool in the packages real users will download
and install?  If not, this is probably rtm-.
Comment 12 Scott Collins 2000-10-29 13:33:25 PST
Uh, sure, I can check in shaver's patch.  Or shaver can take this bug and check
it in himself, whichever is best.  Where do we want this?  trunk only?  or trunk
and branch?
Comment 13 Frank Belew 2000-10-29 17:25:29 PST
> Is there any actual usage of this tool in the packages real users will
> download and install?  If not, this is probably rtm-.

This tool is used by me in the debian packages, and by blizzard in the RPMs.
It will probably be used by any other person on a multi-user OS. 

So no, it isn't used by the official mozilla tarballs on the official ftp site
but that should not be a reason to just dismiss it
Comment 14 Daniel Veditz [:dveditz] 2000-10-29 20:28:54 PST
Either way (trunk or branch) this needs a sr=. Since shaver wrote the patch scc 
should be able to provide the sr=.

Then if you don't want to fight PDT red tape that's all you need to check into 
the branch, and then mark the bug [rtm-]. If you do want to get this into the 
branch as well then mark the bug [rtm+] after getting the sr= and wait for 
their judgement. Include explanation of why we can't ship Netscape 6 without 
this fix.

To get into the branch this needs a sr= (it has an r= from me) and pdt 
approval. To land on the trunk you still need an sr=. Since Shaver wrote the 
patch scc should be able to supply the sr=.

Comment 15 Scott Collins 2000-11-02 14:08:31 PST
sr=scc

all reviews are in place, do we want this in?  Changing whiteboard status
accordingly
Comment 16 selmer (gone) 2000-11-02 18:29:56 PST
rtm-, not ship stopper.
Comment 17 timeless 2001-02-16 13:36:02 PST
fix checked in
Comment 18 timeless 2002-05-16 12:13:40 PDT
*** Bug 145060 has been marked as a duplicate of this bug. ***
Comment 19 timeless 2002-05-16 12:26:53 PDT
no one verified, but someone filed this bug again. back to the drawing board.
Comment 20 timeless 2002-05-16 12:37:07 PDT
this is now relnoted.
i'm gone until sunday and don't intend to look at this before monday,
so if this is important to anyone they should look into it ASAP.

otoh in practice today's probably the last day for 1.0 so by the time you read 
this comment you've probably run out of time for that.
Comment 21 Scott Collins 2002-11-03 13:44:21 PST
why was the bug re-opened?  did something regress the previously checked in
patch?  timeless?  what's up with this?  re-assigning to you since all the
activity seems to be you.
Comment 22 timeless 2003-03-06 15:01:55 PST
Breakpoint 2, 0x4037a540 in mkdir () from /lib/libc.so.6
(gdb) where
#0  0x4037a540 in mkdir () from /lib/libc.so.6
#1  0x4010a568 in do_mkdir (path=0x8083a88 "/tmp/test/.mozilla", flags=170,
mode=509, _retval=0xbffff028)
    at /mnt/ibm/mozhack/mozilla/xpcom/io/nsLocalFileUnix.cpp:383
#2  0x4010a5e4 in nsLocalFile::CreateAndKeepOpen (this=0x80839f8, type=1,
flags=170, permissions=509,
    _retval=0xbffff028) at /mnt/ibm/mozhack/mozilla/xpcom/io/nsLocalFileUnix.cpp:397
#3  0x4010a6f8 in nsLocalFile::Create (this=0x80839f8, type=1, permissions=509)
    at /mnt/ibm/mozhack/mozilla/xpcom/io/nsLocalFileUnix.cpp:437
#4  0x400d3b01 in nsAppFileLocationProvider::GetProductDirectory
(this=0x80541b0, aLocalFile=0xbffff1e8)
    at /mnt/ibm/mozhack/mozilla/xpcom/io/nsAppFileLocationProvider.cpp:392
#5  0x400d31e7 in nsAppFileLocationProvider::GetFile (this=0x80541b0,
prop=0x401977e5 "UserPlugins",
    persistant=0xbffff238, _retval=0xbffff234)
    at /mnt/ibm/mozhack/mozilla/xpcom/io/nsAppFileLocationProvider.cpp:248
#6  0x400d47bf in nsAppDirectoryEnumerator::HasMoreElements (this=0x8050028,
result=0xbffff300)
    at /mnt/ibm/mozhack/mozilla/xpcom/io/nsAppFileLocationProvider.cpp:463
#7  0x400d4f1f in nsPathsDirectoryEnumerator::HasMoreElements (this=0x8050028,
result=0xbffff300)
    at /mnt/ibm/mozhack/mozilla/xpcom/io/nsAppFileLocationProvider.cpp:551
#8  0x4014afb8 in AppendFromDirServiceList (codename=0x401b9621 "APluginsDL",
aPath=0x804ffe8)
    at
/mnt/ibm/mozhack/mozilla/xpcom/reflect/xptinfo/src/xptiInterfaceInfoManager.cpp:215
#9  0x4014b447 in xptiInterfaceInfoManager::BuildFileSearchPath (aPath=0xbffff3e8)
    at
/mnt/ibm/mozhack/mozilla/xpcom/reflect/xptinfo/src/xptiInterfaceInfoManager.cpp:273
#10 0x4014a531 in xptiInterfaceInfoManager::GetInterfaceInfoManagerNoAddRef ()
    at
/mnt/ibm/mozhack/mozilla/xpcom/reflect/xptinfo/src/xptiInterfaceInfoManager.cpp:64
#11 0x40152088 in XPTI_GetInterfaceInfoManager ()
    at
/mnt/ibm/mozhack/mozilla/xpcom/reflect/xptinfo/src/xptiInterfaceInfoManager.cpp:2128
#12 0x4009fa0a in NS_InitXPCOM2 (result=0xbffff5f0, binDirectory=0x0,
appFileLocationProvider=0x0)
    at /mnt/ibm/mozhack/mozilla/xpcom/build/nsXPComInit.cpp:598
#13 0x0804afad in main (argc=1, argv=0xbffff664)
    at /mnt/ibm/mozhack/mozilla/xpcom/tools/registry/regxpcom.cpp:182
#14 0x402cd17d in __libc_start_main () from /lib/libc.so.6
(gdb) up
#1  0x4010a568 in do_mkdir (path=0x8083a88 "/tmp/test/.mozilla", flags=170,
mode=509, _retval=0xbffff028)
    at /mnt/ibm/mozhack/mozilla/xpcom/io/nsLocalFileUnix.cpp:383
383         return mkdir(path, mode);
(gdb)

So the problem is that nsAppFileLocationProvider::GetProductDirectory absolutely
creates the directory, it doesn't appear that it needs to.
unfortunately my first xpcshell test run resulted in bug 196241
Comment 23 timeless 2003-03-06 15:03:20 PST
Created attachment 116482 [details] [diff] [review]
change nsAppFileLocationProvider::GetProductDirectory to return what the directory would be without forcing it to exist
Comment 24 Bastiaan 2003-03-18 16:58:24 PST
Hi,  Did the install on Mandrake 9 as root. -Choose to delete old mozilla stuff -Received error [ERROR]Fatalerror (-616): Extraction of XPCOM failed[/ERROR] -Read about this bug -Tried the script... no luck there is no mozzila anymore on my machine -Only the users-stuff is hanging around at user level.  What to do? Is this the save bug?  thanx,       Bastiaan  
Comment 25 R.K.Aa. 2003-03-23 16:32:26 PST
*** Bug 198863 has been marked as a duplicate of this bug. ***
Comment 26 Benjamin Smedberg [:bsmedberg] 2009-07-24 12:11:18 PDT
regxpcom doesn't exist any more

Note You need to log in before you can comment on or make changes to this bug.