[snap] cannot use shared NSS db

Bug #1859643 reported by Olivier Tilloy
This bug affects 9 people
Affects Status Importance Assigned to Milestone
chromium-browser (Ubuntu)
firefox (Ubuntu)

Bug Description

(initially reported at https://askubuntu.com/questions/1202861/chromium-does-not-show-certificates-from-pki-nssdb)

Chromium can theoretically use the shared NSS db at ~/.pki/nssdb, but the snap confinement prevents it from actually using the shared db (it reads and writes to $SNAP/.pki/nssdb instead).

Shared certificates can be inspected by browsing to chrome://settings/certificates.

Really accessing the shared db would require an additional read/write personal-files plug on $HOME/.pki/nssdb, and patching GetDefaultConfigDirectory() in crypto/nss_util.cc.

Tags: snap
Revision history for this message
Jamie Strandboge (jdstrand) wrote :

OTOH, I think it makes sense to allow for the ability to share ~/.pki/nssdb (and yes, a personal-files addition along with a snap change (perhaps just a symlink from $SNAP_USER_DATA/.pki/nssdb to ~/.pki/nssdb would be enough rather than patching?).

For read access, I have no problem with using personal-files to read the nssdb into $SNAP_USER_DATA, with auto-connection.

For write, chromium is not the clear owner of this directory, so I would be hesitant to recommend it as a default since IMO, chromium shouldn't be writing out to these files even in non-snap situations (again, perfectly reasonable to merge in changes if the user desires). I for one would be rather surprised to install a certificate via chromium and have it reflected in my session-wide nssdb for another application (eg, libvirt). Furthermore, there is nothing saying that nssdb might not change format incompatibly with nss in the chromium snap and software installed on the system. This is not theoretical: rather than using a single nssdb in the user's global ~/.pki/nssdb dir, firefox, for example, instead stores per-profile certN.db files in ~/.mozilla/firefox/<profile>/* and in my profile dirs I have a mixture of cert8.db and cert9.db. I do see that chromium only has cert9.db, so perhaps this is handled by the library itself (again, someone would need to verify), but then there is nssdb skew if some applications are writing to certN-1.db, some to certN.db and others to certN+1.db.

Revision history for this message
Olivier Tilloy (osomon) wrote :

Closely related: bug #1899478.

Revision history for this message
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in firefox (Ubuntu):
status: New → Confirmed
Olivier Tilloy (osomon)
Changed in chromium-browser (Ubuntu):
assignee: Olivier Tilloy (osomon) → nobody
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.