Closed Bug 205053 Opened 21 years ago Closed 20 years ago

Mozilla run with sudo root privileges causes bookmarks.html owner change and subsequent Bookmarks loss

Categories

(Core Graveyard :: Profile: BackEnd, defect)

Product:
Core Graveyard
Component:
Profile: BackEnd
Platform:
x86
Linux
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

(Not tracked)

Status:
VERIFIED WONTFIX

People

(Reporter: mowat, Unassigned)

References

Details

(Keywords: relnote) 

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4b) Gecko/20030507
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4b) Gecko/20030507

I installed the May 6 nightly build and somewhere during the install process
all of my bookmarks were lost.  I recovered them from a snapshot.  I installed
Mozilla 1.4b today and the same thing happened.  Marking this critical since
there is data loss.


Reproducible: Always

Steps to Reproduce:
1) download and install the tar image in /usr/lib/mozilla
2) browser starts with classic skin
3) change the skin to modern
4) restart the browser.

I noticed at this point that all bookmarks were lost. I didn't happen to
see if it was at step 2 or step 4 that they disappeared.
More info:  reinstalled and noticed that my bookmarks were owned by root
(I had to install as root):

-rw-------    1 root     root        24535 May  9 10:10 bookmarks.html

chowned the bookmarks to my self and exited the browser:
-rw-------    1 mowat    gopher        272 May  9 10:19 bookmarks.html

restored my copy and everything seems ok now.
I also lost my bookmarks with Mozilla 1.4b on Linux. Here are the steps to
reproduce the problem :
1. Launch "sudo mozilla" -> bookmarks.html owner is changed to root (in normal
users's profile directory)
2. Quit mozilla
3. Launch mozilla as normal user, without sudo -> the user cannot read the
bookmarks.html file, bookmarks are empty
4. Quit mozilla -> the bookmarks.html formerly owned by root is deleted and
replaced by an empty one (owned by normal user)

I often use "sudo mozilla" to install components like "piemenus", since I
installed Mozilla from RPMs and need write access to the directory
/usr/lib/mozilla-1.x

I noticed the same thing happen with the May 28 nightly build (1.5a) on WinXP. 
 I uninstalled 1.4b and installed the nightly.  It picked up my old profile,
including theme, prefs, and mail, but wiped clean my bookmarks.html file.    
I know that it is not the best practice to use profiles from older versions, but
 it's just worked out so easy up to this point.
Same as #205200
Blocks: bookmark-loss
*** Bug 224808 has been marked as a duplicate of this bug. ***
Summary: Bookmarks lost when installing Mozilla 1.4b → Bookmarks lost when installing Mozilla with sudo
*** Bug 229619 has been marked as a duplicate of this bug. ***
Actually the problem is that Installer runs Mozilla with su privileges at the
end of installation process.

The simple solution: Installer running with su privileges should NOT run Mozilla.

Clarifying summary and confirming bug...
Status: UNCONFIRMED → NEW
Component: Bookmarks → Installer
Ever confirmed: true
Keywords: dataloss
Summary: Bookmarks lost when installing Mozilla with sudo → Installer runs Mozilla with su privileges causing bookmarks.html owner change and subsequent Bookmarks loss
*** Bug 205200 has been marked as a duplicate of this bug. ***
> Actually the problem is that Installer runs Mozilla with su privileges at the
> end of installation process.
> 
> The simple solution: Installer running with su privileges should NOT run 
> Mozilla.

Actually, the problem is that you're NOT using su.  You're using sudo.  su sets
the HOME environment variable to /root and sudo leaves it.  Mozilla uses the
HOME environment variable to find the profile directory.  You can set
PROFILE_HOME to /root to override the HOME variable.

http://lxr.mozilla.org/mozilla/source/profile/src/nsProfileAccess.cpp#1154

I don't think there's anything Mozilla should be doing different here...
I'm not talking about ``su'' program. 
I'm talking about ``su privileges'' = ``superuser privileges'' = ``root
privileges'' etc. To avoid misreading, I've slightly changed the summary.

I think, running Installer with root privileges should be considered as
SYSTEM-WIDE Mozilla installation/update rather than local installation Mozilla
for user ``root''. That why it should NOT run Mozilla since it's not known
apriori which users supposed to use Mozilla.

Say, I never run Mozilla being a root (and think, it's quite dumb to work in X
being root). But to perform system-wide installation I have to run Installer
with root privileges, and do NOT expect it to run Mozilla.

Of course, it's possible that somebody works as a root (which is a rare case, I
think). But not running Mozilla by Installer for such root user would not cause
problem. He could run Mozilla himself right after installation.

On the other hand, Installer with root privileges silently running Mozilla
causes a lot of problems.
Summary: Installer runs Mozilla with su privileges causing bookmarks.html owner change and subsequent Bookmarks loss → Installer runs Mozilla with root privileges causing bookmarks.html owner change and subsequent Bookmarks loss
> That why it should NOT run Mozilla since it's not known apriori which users 
> supposed to use Mozilla.

The installer (currently) has to run Mozilla as the user that installed it.  
see bug 42184 comment 74 and bug 57089.
If there is a necessity of Mozilla run to complete installation, I'd suggest a
special option for such run, say, -Install.
``mozilla -Install'' would perform whatever it needs to complete installation,
and exit immediately after that. No profile manager would be run and no profile
loaded/altered. I know such run is possible since currently I use the following
workaround for the problem.

I have a dummy user, so on Mozilla start I'm always asked which profile of two,
my real or dummy, I want to use. When Mozilla is run by Installer, I simply hit
[Exit] button in Profile Manager window and avoid potential problems (the
subject of this bug). 
So Mozilla starts and updates whatever it needs, but no actual profile is
loaded/altered.

Of course, there is an incovenience of having to go through Profile Manager
selection on each Mozilla start.
Depends on: 57089
*** Bug 209975 has been marked as a duplicate of this bug. ***
*** Bug 223384 has been marked as a duplicate of this bug. ***
One more workaround: perform installation while mozilla is running. Running
Mozilla locks profile and prevents Installer's run of Mozilla from
openning/altering the profile.

Oh, no!
I can't believe it!
You knew about this _critical_ bug for about an year, and it is still not
mentioned in installation instructions!!!

I've just installed mozilla-1.6 via 'sudo ./mozilla-installer' command, and lost
all of my bookmarks :(
It was very "clever" decision to run mozilla automatically after the installation.

*** Bug 239440 has been marked as a duplicate of this bug. ***
the relevant installer bug is 57089

this is a profile bug.  see comment 9
Assignee: p_ch → nobody
Component: Installer → Profile Manager BackEnd
QA Contact: chrispetersen → core.profile-manager-backend
Note that this bug does NOT only happen if you run the installer.  It also
changes the ownership (in 1.6) if you simply RUN mozilla as root with your user
environment.

I submitted a duplicate of this bug.  I saw this bug's title during a quick
search  but missed it because when I searched it said "installer" and I didn't
run the installer... just mozilla as root with user env.
Summary: Installer runs Mozilla with root privileges causing bookmarks.html owner change and subsequent Bookmarks loss → Mozilla run with sudo root privileges causes bookmarks.html owner change and subsequent Bookmarks loss
Is this bug gone?
I've installed yesterday build and Installer did not run Mozilla at the end of
the installation process. Hurray!

Max: that's bug 57089.  see comment 9, comment 18 and the dependency.

What remains is that if you actually run Mozilla with sudo *on purpose*, this
bug will still occur.

So this bug will likely remain open until a developer decides what to do with it.
*** Bug 236593 has been marked as a duplicate of this bug. ***
*** Bug 212447 has been marked as a duplicate of this bug. ***
This bug has bitten me several times with the Firefox installer.  What I'm
wondering is why does the browser feel that it has to change the owner of the
bookmarks file, but nothing else?  If the browser has read/write access to the
file, it should leave the ownership alone.
(In reply to comment #24)
> This bug has bitten me several times with the Firefox installer.  What I'm
> wondering is why does the browser feel that it has to change the owner of the
> bookmarks file, but nothing else?  If the browser has read/write access to the
> file, it should leave the ownership alone.

I haven't read the code, so I'm just guessing here, but I suspect the problem is
that firefox is writing a new bookmarks file, removing the old one, and moving
the new one into place.  So the newly created file gets created with the "wrong"
ownership.
(In reply to comment #25)
> I haven't read the code, so I'm just guessing here, but I suspect the problem is
> that firefox is writing a new bookmarks file, removing the old one, and moving
> the new one into place.  So the newly created file gets created with the "wrong"
> ownership.

You appear to be right, according to my perusal of the code.  It shouldn't be
too difficult to work around, hypothetically, although it's hard to decide what
would be the Best Solution.

1) Create the new bookmarks file, then chown(2) it to the owner of the original
before/after moving it.
2) Don't save bookmark changes if we don't own the bookmarks.html file.

Choice 1 is probably better.  Personally, I think just not running the browser
at the end of the installer (comment 7) is a poor solution.  What if someone is
in a `sudo -s` shell, and mistakenly runs it?  The bookmarks will still be gone
the next time the user runs it as themselves.

As I know this only happens in sudo environments if you start with "su -" then
this doesn't happen.

So the problem is, if you are another user as the $HOMEDIR points to.
Keywords: relnote
If you want to run Mozilla as root, and use sudo, use sudo -H to reset $HOME. 
Or, better, just don't do that, and use su -.  Or install the extensions by hand
with unzip and manual installation.

chown isn't an option in the general case, and isn't good behaviour regardless.
 Many, many apps have this behaviour; it's what it means to run as a different user.

Removing dataloss keyword, because data isn't lost, it's just not visible to the
user other than the one that created the most recent revision of the bookmarks
file.  File permissions for the win.

WONTFIXing because Mozilla shouldn't spend code-size or programmer-time
preventing this flavour of user error.  If you're running commands as root, you
should know what they do.  We _should_ perhaps report -EPERM on failure to open
the bookmarks file or other profile elements, to help users diagnose cases where
they've shot themselves like this.  That's another bug, though.
Keywords: dataloss
(Ahem, I said WONTFIX.)
Status: NEW → RESOLVED
Closed: 20 years ago
Resolution: --- → WONTFIX
shaver: is the EPERM => nsresult bug on file?

/be
Status: RESOLVED → VERIFIED
Here's my previous description of this problem:
http://bugzilla.mozilla.org/show_bug.cgi?id=203343#c27

My guess is that Mozilla currently creates a new bookmark file as follows: it
reads the existing bookmarks at some stage, merges changes instructed by the
user (add, remove, modify) and then at some stage needs to recreate
bookmarks.html. One would hope that it's writing to a /second/ file (which gets
created with the ownership of the current UID) and then renames the existing
file to a backup, renames the new file to 'bookmarks.html', verifies it's
written correctly and then deletes the backup. This is the sensible way to do
this anyway...

If my guesses are accurate, then solution is pretty simple - instead of
/renaming/ the existing bookmarks.html to create the backup, /copy/ it instead.
/Copy/ the new file over the top of the existing one too. This preserves the
original file ownership and permissions. Problem solved.

Please, don't tell me Mozilla is irresponsible and simply deletes and then
writes a new file - I don't want to hear that - that's just too horrendous to
contemplate...

*** keep backups *** :)
mozilla:
1. writes a new file
2. if it fails, gives up and might kill the new file
3. renames the old file
4. renames the new file
5. if it's happy, kills the old file
(In reply to comment #32)
> mozilla:
> 1. writes a new file
> 2. if it fails, gives up and might kill the new file
> 3. renames the old file
> 4. renames the new file
> 5. if it's happy, kills the old file

Right, so to resolve this issue steps 3 and 4 should be changed to:

3. copy the old file (bookmarks.html) to bookmarks.html.old
4. copy the new file (bookmarks.html.new) to bookmarks.html

The original permissions are therefore preserved.

(Try this if you don't believe me - create a file test.orig owned by non-root.
Create test.new as root user. Copy test.new to test.orig and note the file is
*still* owned by the original non-root user).



> 3. copy the old file (bookmarks.html) to bookmarks.html.old
> 4. copy the new file (bookmarks.html.new) to bookmarks.html

File moves are atomic (on the same FS, at least), while file copies are not.
This is not an acceptable solution.
> Removing dataloss keyword, because data isn't lost, it's just not visible to the
user other than the one that created the most recent revision of the bookmarks
file.

If the things are stated this way, then bug 236593 "bookmarks file owned by
different user deleted without warning" or similar should be reopened. Dataloss
does silently happen.
(In reply to comment #34)
> > 3. copy the old file (bookmarks.html) to bookmarks.html.old
> > 4. copy the new file (bookmarks.html.new) to bookmarks.html
> 
> File moves are atomic (on the same FS, at least), while file copies are not.
> This is not an acceptable solution.

And the current situation is acceptable? Incredible. I find your comment amazing
- we're already experiencing total data loss!

Steps 3 and 4 don't need to be atomic - step 5 checks the result and should be
smart enough to restore the original file (yes, with a rename this time) if
things go wrong. There's no need to make steps 3 and 4 atomic. However it might
be prudent if you're really concerned about reliability to check the backup in
step 3 is OK before proceeding.

A design decision needs to be made - how important is bookmarks.html? What are
the likely failure modes? I would argue that bookmarks represent hours of 'work'
by some users, collected over a long period. To lose them can be traumatic and
is not a good experience for the user. Everyone I know who runs Mozilla in Linux
and has tried to install an extension with sudo has nuked their bookmarks file.
It's unacceptable - this should never happen!

At the very *least* mozilla should not truncate a file because it has write
access to the directory but not access to the file. We can take a preventative
solution as outlined above, or we can detect this situation (check ownership and
permissions on file before trying to do anything with it, and leave it alone if
we can't) and alert the user, prompting for intervention. 

Currently, mozilla does neither - *this* is not an acceptable situation.


(In reply to comment #35)
> > Removing dataloss keyword, because data isn't lost, it's just not visible to 

(Can't find source of original quote)

There is data loss - the file is owned by a different user (root), yes, but when
the original user runs Mozilla, it ends up *truncating* the file (since the user
has write permissions to the container directory but not to the file - you can
truncate or delete someone elses file in your own writable directory, you just
can't overwrite it with anything).

The loss is complete. No more bookmarks. At all.


Would a simple solution be to fix the installer to detect that it was invoked
without sudo -H?

e.g. 
if [ $UID -eq 0 -a $HOME != "/root" ]; then
        echo "use sudo -H";
fi
(In reply to comment #38)
> Would a simple solution be to fix the installer to detect that it was invoked
> without sudo -H?

This bug isn't limited to the installer - it happens any time you run Mozilla
via sudo to install a 'system-wide' extension (e.g. multizilla). The installer
sets the ownership to root as you noted in comment #1, but if you run mozilla at
that point as the non-root user, you will lose your bookmarks.

You can't "check and restore" without file locks and other (space reservation)
guarantees, in place of atomicity.  That's just not how it works, sadly.

It does sound like there's a dataloss issue here, buried under a pile of noise
about checking ownership and chowning and verifying $HOME.  Someone should file
a bug with a summary like "bookmarks should not be re-written if initial read
fails", I think, since it'll keep us away from the sudo and file ownership
issue.  Someone else might want to write a patch and attach it, to expedite a fix.

(Additionally, dave.antliff, you _can't_ truncate a file to which you do not
have write permissions -- ownership is not the issue here at all -- on any even
remotely POSIX system.)
(Also, I feel compelled to bang the drum one more time about the need for an
extension installer which doesn't require an administrator to run Mozilla.  That
would be a welcome contribution, IMO.)
(In reply to comment #40)
> It does sound like there's a dataloss issue here, buried under a pile of noise
> about checking ownership and chowning and verifying $HOME.  Someone should file
> a bug with a summary like "bookmarks should not be re-written if initial read
> fails", I think, since it'll keep us away from the sudo and file ownership
> issue.  Someone else might want to write a patch and attach it, to expedite a fix.
> 
> (Additionally, dave.antliff, you _can't_ truncate a file to which you do not
> have write permissions -- ownership is not the issue here at all -- on any even
> remotely POSIX system.)

Yes, I stand corrected - however you can delete a file that you have no
permissions to if you have write permissions to the current directory. This is
what Mozilla is doing I think.

I tried a few things:

1. made bookmarks.html root:root -rw-------    :  Mozilla starts, can't read
bookmarks, deletes existing file, creates empty (272 byte) replacement.
Bookmarks gone.

2. made bookmarks.html root:root -rw-r--r--    :  Mozilla starts, can read
bookmarks fine, recreates bookmark file with proper ownership. Everything ok.

So I agree with you - if the initial read fails, Mozilla should not attempt to
rewrite the bookmark file, as it will replace it with an 'empty' file.

New bug filed here:
http://bugzilla.mozilla.org/show_bug.cgi?id=251456
Ok, I give up. Enough wasting my time with this ****:

http://bugzilla.mozilla.org/show_bug.cgi?id=251456#c1
Depends on: 251456
I use another workaround. I put the following script under /usr/local/bin/mozilla

--snip--
#/bin/sh

/usr/bin/mozilla "$@"

REALHOME=$(awk 'BEGIN {FS=":"} /^'${USER}':/{print $6}' /etc/passwd)

if [ -n "$SUDO_UID" -a "$REALHOME" != "$HOME" ]; then
    chown -R ${SUDO_UID}:${SUDO_GID} ${HOME}/.mozilla
fi
--snap--

So whenever I or program I run happen to start mozilla via sudo, after exiting
mozilla the ownership of all files in ~/.mozilla is reverted to me. If I run
mozilla as me or via sudo -H, file ownership need not be reverted. Obviously,
for this to work /usr/local/bin must precede /usr/bin in your $PATH.
(In reply to comment #44)

> #/bin/sh

Err, "#!/bin/sh" of course.
*** Bug 280416 has been marked as a duplicate of this bug. ***
Product: Core → Core Graveyard
See Also: → 1323302
You need to log in before you can comment on or make changes to this bug.