Closed Bug 251456 Opened 20 years ago Closed 12 years ago

bookmarks.html should not be re-written if initial read fails

Categories

(SeaMonkey :: Bookmarks & History, defect)

Product:
SeaMonkey
Component:
Bookmarks & History
Platform:
x86
Linux
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

(Not tracked)

Status:
RESOLVED INVALID

People

(Reporter: dave.antliff, Unassigned)

References

Details

(Keywords: dataloss) 

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7) Gecko/20040714 MultiZilla/1.6.4.0b
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7) Gecko/20040714 MultiZilla/1.6.4.0b

If bookmarks.html exists but cannot by read by Mozilla (e.g. owned by a
different user, no read permissions) then Mozilla currently re-writes a new
'empty' bookmark file in it's place. The result is data loss, as the contents of
the original bookmarks file is lost.

This has implications when Mozilla is run via sudo to install extensions - a
user can lose all bookmarks.

Reproducible: Always
Steps to Reproduce:
1. Set ownership of non-root user's bookmarks.html to root:root
2. Set permissions to u=rw (600 -rw-------)
3. Run Mozilla as the non-root user

Actual Results:  
bookmarks.html is replaced by 'emtpy' 272 byte file. Any existing bookmarks are
lost.


Expected Results:  
If Mozilla fails to read an existing bookmarks.html, then it should not attempt
to write a replacement file.


Data loss.
your suggestion is fairly looney, you also picked a fairly poor component for
this bug.

if I can't read bookmarks and proceed to bookmark a bunch of pages, i shouldn't
loose my newly bookmarked content just because you did something silly and want
to be protected from that.

come up w/ a better solution. warning: this requires some user interface design,
and you never want to have to do that. stay away from dialogs.
Assignee: nobody → p_ch
Component: Profile: BackEnd → Bookmarks
QA Contact: core.profile-manager-backend → seamonkey.bookmarks
if you install an extension as root with false $HOME ... why the hell will the
bookmarks change there owner if already one exists?
(In reply to comment #3)
> if you install an extension as root with false $HOME ... why the hell will the
> bookmarks change there owner if already one exists?

This is explained *at length* here:

http://bugzilla.mozilla.org/show_bug.cgi?id=205053#c32

and beyond. Your question is the basis for this bug report.

Follow the links, people!
Blocks: 205053
Blocks: bookmark-loss
Keywords: dataloss
Don't piss on me, explain/help me on following: 
 
1st) When does mozilla change bookmarks.html permission to root (I know on 
first install as root with false $home it is set to root. I know it seems do 
it if you upgrade with false $home). 
 
2nd) Does it this also when you start mozilla with false $home? (For example 
if you update an extension system wide). Is the bookmark on every start 
recreated? Cause normaly root can read bookmarks.html so no need to change 
priviliges. And it this happens, then we need first find out, why this 
happens. 
 
But anyway, why the hell someone starts mozilla with false $home directory? 
 
If initial read fails, it should recreate bookmarks.html but it shouldn't 
change owner to root (in this example). 
(In reply to comment #5)
> 1st) When does mozilla change bookmarks.html permission to root (I know on 
> first install as root with false $home it is set to root. I know it seems do 
> it if you upgrade with false $home). 

If you run Mozilla via 'sudo' (therefore as root but maintaining user
environment, including $HOME) then due to the way Mozilla maintains
bookmarks.html (rename to backup, create new file) the new bookmarks.html ends
up owned by root, since Mozilla is running as UID root at that point.
  
> 2nd) Does it this also when you start mozilla with false $home? (For example 
> if you update an extension system wide). Is the bookmark on every start 
> recreated? Cause normaly root can read bookmarks.html so no need to change 
> priviliges. And it this happens, then we need first find out, why this 
> happens. 

It's when you run Mozilla the second time (as non-root user) after running it
the first time with 'sudo', that it is unable to read bookmarks.html (since root
owns it and it's permissions are u=rw) and it creates a new bookmarks.html with
nothing in it.
  
> But anyway, why the hell someone starts mozilla with false $home directory? 

sudo.

> If initial read fails, it should recreate bookmarks.html but it shouldn't 
> change owner to root (in this example). 

It's not quite as simple as this - please read my other posts for this bug and
the ones referenced.

So the change of bookmarks.html to user root only happens after mozilla 
installer on the so called first start. 
 
--> You should read the installation nodes first. 
 
So it haven't to do with installing a new extension system wide cause there 
isn't mozilla first start not called (IMHO). So the bookmarks.html don't chown 
to root. And so the bookmarks.html is readable afte you change back to normal 
user. 
Please, can we avoid losing this bug to back-and-forth error propagation like we
did 205053?

I think a dialog for this case is fine, especially if we defer touching the
bookmarks file until we've actually made a change to it.  We don't have to give
the user a choice, just an alert that says "your bookmarks were unreadable by
&product.shortName; we've moved the old file to <path>/bookmarks.save-1.html for
your later use".

This problem is exacerbated by the fact that we write bookmarks whenever we
exit, even if nothing has changed, of course.
Assignee: p_ch → vladimir
If we can't read the bookmarks.html, then we also can't rename/move the file.

But that we always resave the bookmarks file on shutdown is the thing I missed.
(In reply to comment #9)
>If we can't read the bookmarks.html, then we also can't rename/move the file.
At least on Unix, then yes, we can remove an unreadable file.
(In reply to comment #9)
> If we can't read the bookmarks.html, then we also can't rename/move the file.

As comment #10 mentioned, yes we can remove or rename the file, since the user
has write access to the container directory. If the user does not, then the move
will fail, but this does not happen with *this* bug.

Changing status to NEW.
Status: UNCONFIRMED → NEW
Ever confirmed: true
(In reply to comment #8)
>This problem is exacerbated by the fact that we write bookmarks whenever we
>exit, even if nothing has changed, of course.
This is fixable, we just need to fix nsBookmarksService::Observe to wrap its
calls to Flush() in an if (mDirty) as per FireTimer.
Nominating for blocking-aviary1.0 and blocking1.7.x.  Someone was just on IRC
saying this happened to them.

While I agree that running mozilla as root is not a smart thing to do, it should
not delete your bookmarks every time you install an xpi as root.
Flags: blocking1.7.x?
Flags: blocking-aviary1.0?
*** Bug 231792 has been marked as a duplicate of this bug. ***
*** Bug 261185 has been marked as a duplicate of this bug. ***
Yes, I know i duped an older bug to this one, but this one had more information
in it than the older one.
Minusing for 1.0; no time to add the dialog UI, and we're already past
localization freeze.
Flags: blocking1.7.x?
Flags: blocking1.7.x-
Flags: blocking-aviary1.0?
Flags: blocking-aviary1.0-
Product: Browser → Seamonkey
This bug seems to be fixed.  Can someone please confirm.  Using nightly build:
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8a6) Gecko/20041212
Ok, I haven't read everything here. Sorry.  But here are the results of my
experience with the bookmarks.html file using Mozilla 1.4.3 and a workaround:

1.) I tried copying over the bookmarks.html file in the
~/.mozilla/defaults/whatever directory.  I also copied the desired
bookmarks.html file to ALL bookmarks.html files in any other versions of mozilla
on my computer (i.e. /usr/lib/mozilla /usr/lib/mozilla-1.4.3 ......)  Every time
I reloaded mozilla bookmarks.html in the .mozilla directory was overwritten with
the default file.  I changed permissions even to r--------  !!  it change it
back to rw------- and the default file.

2.) Workaround:  I simply went to Bookmarks-->Manage Bookmarks... and DELETED
every bookmark and folder I could.  I also renamed the "personal toolbar" folder
to something else ("blah" in my case).  Copied over the
./mozilla/../../bookmarks.html file again and this time it wasn't rewritten.

The End   Sorry again for my newbiness, please feel free to explain to me how I
should have made this report.  Thanks.
Vlad:  Since this missed 1.0 and 1.0.1, any idea if we can get this in for 1.0.2
or 1.1?  It seems as if this particular issue is leading to dataloss for many
different cases.
Flags: blocking-aviary1.1?
See also bug 251692, same bug for Firefox.
No comments in 2½ years.

(In reply to comment #22)
> See also bug 251692, same bug for Firefox.

Firefox 3, and maybe (but it's less certain) SeaMonkey 2, will get a brand-new bookmarks storage system, not in HTML anymore but in sqlite format. If they go their separate ways, the fix to bug 251692 will probably not apply here.
This bug concerns the old bookmarks.html code in XPFE. Both Firefox and SeaMonkey have been using the (new) Places implementation for some time now. Closing this obsolete bug.
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.