Page MenuHome GnuPG

Permissions of pubkey.kbx not retained through changes
Closed, WontfixPublic

Description

When changes are made to pubring.kbx, the file is moved to pubring.kbx~ and a
new file is created with permissions based on the user's umask. This should
probably be created with the permissions of the original file, or read/write for
only the owner. Observed with GnuPG 2.1.17.

Example, with different umasks:

[user@host ~/.gnupg]$ ls -l pubring*
-rw------- 1 user group 5632 Jan 17 20:00 pubring.kbx
-rw------- 1 user group 4453 Jan 17 20:00 pubring.kbx~
[user@host ~/.gnupg]$ umask 0000
[user@host ~/.gnupg]$ gpg --edit-key anykey

<make some changes and save>

[user@host ~/.gnupg]$ ls -l pubring*
-rw-rw-rw- 1 user group 4453 Jan 17 20:01 pubring.kbx
-rw------- 1 user group 5632 Jan 17 20:00 pubring.kbx~
[user@host ~/.gnupg]$ umask 0027
[user@host ~/.gnupg]$ gpg --edit-key anykey

<make some changes and save>

[user@host ~/.gnupg]$ ls -l pubring*
-rw-r----- 1 user group 3829 Jan 17 20:02 pubring.kbx
-rw-rw-rw- 1 user group 4453 Jan 17 20:01 pubring.kbx~

Initial creation of tofu.db is also based on the user's umask, unlike other
files (such as trustdb.gpg), though write permissions are not granted to
group/other.

Details

Version
2.1.17

Event Timeline

I don't consider this a minor bug.

The pubring does not contain secret information but only sensitive data, like
many files in a user's $HOME. The umask is the standard Unix way of restricting
access for new files. For files holding secret data we explicitly set the
permissions.

werner lowered the priority of this task from Normal to Low.Jan 23 2017, 10:06 AM

I nearly filed this as a minor bug to start with. Apologies for the
mis-classification.

My thinking was that there are a few rarer cases on unattended/shared
environments where this may be an issue. Scripts may deliberately be using a
umask that allows write permission to files it's creating, not expecting that
pubring (or other keyring) changes will create a new file. Other users/services
may need read permission to those keyrings, and actually end up with write
permission. This is potentially a problem despite the data not being secret.

Granted, the above hypothetical situation is uncommon and easily worked around
with better design/testing, but it might catch people out.

werner claimed this task.

Eventually we will move to keyboxd which is already an experimental option in 2.3. Thus we won't do anything here.