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)
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.
Updated•22 years ago
|
Assignee | ||
Comment 3•22 years ago
|
||
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
Assignee | ||
Comment 4•22 years ago
|
||
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
Updated•8 years ago
|
Product: Core → Core Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•