[snap] cannot use shared NSS db

[Olivier Tilloy]

(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.

[Jamie Strandboge (jdstrand)]

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.

[Olivier Tilloy (osomon)]

Closely related: bug #1899478.

[Launchpad Janitor (janitor)]

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