Closed Bug 119357 Opened 23 years ago Closed 22 years ago

Browser should lock security database files while running

Categories

(Core Graveyard :: Security: UI, defect, P2)

Other Branch
x86
Linux
defect

Tracking

(Not tracked)

VERIFIED WONTFIX
psm2.2

People

(Reporter: KaiE, Assigned: KaiE)

References

Details

Not sure whether this is a PSM of NSS bug.

On Linux, it is possible to run multiple Mozilla instances at the same time.
Each instance will try to access the same profile data including the security
database files. This can destroy them or at least put them in a bad state.

We should make sure this can't happen. While one instance runs, other instances
should not be able to init itself in read/write mode. They should fall back to
the read/only mode we recently added.

-- Sidenotes:
When I last week used the Linux desktop KDE for the first time, which uses only
single clicks on icons to start an application, I didn't know that, and made a
doubleclick on the Mozilla icon. I was shown that message "there is a problem
with your security database files" as we added it in bug 76915. I was surprised.
But a few moments later the other Mozilla instance (from the first click) came
up and I understood. If we fix this bug to only lock the database, this will
mean, users like me will see a "can't init security database files in read/write
mode", which they won't understand either. I would prefer if Mozilla itself
detected that problem, and clearly indicated to the user that multiple instances
of Mozilla had been started.

On Windows, there is no problem like that, because when Mozilla is started
another time, this gets detected, a "open new window command" is sent to the
running instance, and the newly started instance quits immediately. (At least I
think what I state here is true.)

Dan, you said, we also have to care for roaming, and make sure large cert
database files don't slow things down. That might be a future issue. But that
reminds of something else: When there is no locking done on security database
files, and at the same time two different machines use the same profile coming
from a network drive, we have the same risk of damaged data, as long as we don't
use file based locking.
kai.
Assignee: ssaux → kaie
Priority: -- → P2
Target Milestone: --- → 2.2
nsbeta1
Keywords: nsbeta1
Keywords: nsbeta1nsbeta1-
I believe this is a dupe of 76431, but for now, I'm just making the bug
dependent on it.

I suggest, once 76431 landed, we retest whether this is fixed.

Depends on: 76431
Marking as WONTFIX as bug 76431 has been fixed. Mozilla is now protecting itself
from corruption. However, one could still corrupt the NSS databases by using NSS
commandline tools or older Mozilla versions at the same time.

I think the Mozilla job is done. If we want more protection, it should probably
be done at the NSS level.
Status: NEW → RESOLVED
Closed: 22 years ago
Resolution: --- → WONTFIX
Verified.
Status: RESOLVED → VERIFIED
Product: PSM → Core
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.