[pacman-dev] trustdb locking issues and snippets from the apt changelog
From what I gather, they don't use the trustdb for the reasons we are seeing; instead it looks like they have another keyring named "trusted.gpg" and go forth with the assumption that everything in
Allan and I today, and Denis in the past, noticed some issues with having a shared public key database and locking that gpg wants to do when reading from it. Here is an interesting bit from the apt changelog: apt (0.6.2) experimental; urgency=low * Provide apt-key with a secret keyring and a trustdb, even though we would never use them, because it blows up if it doesn't have them there is to be trusted. -Dan
On 23/04/11 09:32, Dan McGee wrote:
Allan and I today, and Denis in the past, noticed some issues with having a shared public key database and locking that gpg wants to do when reading from it. Here is an interesting bit from the apt changelog:
apt (0.6.2) experimental; urgency=low * Provide apt-key with a secret keyring and a trustdb, even though we would never use them, because it blows up if it doesn't have them
From what I gather, they don't use the trustdb for the reasons we are seeing; instead it looks like they have another keyring named "trusted.gpg" and go forth with the assumption that everything in there is to be trusted.
Looking into this, I believe that we are hitting an entirely separate issue. The reason for a lack of trustdb in the Debian case appears to be more to do with keyring management that anything else. The main issue here is that gpg(me) creates a lock file in the keyrings home directory whenever it uses a keyring. Our keyring directory only has write permissions for the root user and thus when pacman is not being run as root (such as the "pacman -Qip <pkg>" case), it can not create a lock file. We can work around this by making the /etc/pacman.d/gnupg directory have 777 permissions. The {pubring,secring,trustdb},gpg files will still have only root write permissions so I guess this is safe as long as those files are created as part of the pacman package itself... Also, unless I am missing something even if other files are added in that directory by a user, they should not affect gpg. Still... 777 permissions on that directory sounds scary. Anyway, doing this makes the signature validation with -Qip work for non-root users (using Dan's gpg branch WIP patches). Note that GPG itself has an option not to do locking (with a big warning about that being bad...), and I thought maybe we could do that for the non-root usage case, but it looks like gpgme can not do that. Allan
On Sun, Apr 24, 2011 at 11:25:52PM +1000, Allan McRae wrote:
On 23/04/11 09:32, Dan McGee wrote:
Allan and I today, and Denis in the past, noticed some issues with having a shared public key database and locking that gpg wants to do when reading from it. Here is an interesting bit from the apt changelog:
apt (0.6.2) experimental; urgency=low * Provide apt-key with a secret keyring and a trustdb, even though we would never use them, because it blows up if it doesn't have them
From what I gather, they don't use the trustdb for the reasons we are seeing; instead it looks like they have another keyring named "trusted.gpg" and go forth with the assumption that everything in there is to be trusted.
Looking into this, I believe that we are hitting an entirely separate issue. The reason for a lack of trustdb in the Debian case appears to be more to do with keyring management that anything else.
The main issue here is that gpg(me) creates a lock file in the keyrings home directory whenever it uses a keyring. Our keyring directory only has write permissions for the root user and thus when pacman is not being run as root (such as the "pacman -Qip <pkg>" case), it can not create a lock file.
We can work around this by making the /etc/pacman.d/gnupg directory have 777 permissions. The {pubring,secring,trustdb},gpg files will still have only root write permissions so I guess this is safe as long as those files are created as part of the pacman package itself... Also, unless I am missing something even if other files are added in that directory by a user, they should not affect gpg. Still... 777 permissions on that directory sounds scary.
Eh? Giving a directory "777" permissions still allows arbitrary users to delete and subsequently re-create files with write permissions. So this might be a bad idea, here.
Anyway, doing this makes the signature validation with -Qip work for non-root users (using Dan's gpg branch WIP patches).
Note that GPG itself has an option not to do locking (with a big warning about that being bad...), and I thought maybe we could do that for the non-root usage case, but it looks like gpgme can not do that.
Allan
On 24/04/11 23:28, Lukas Fleischer wrote:
On Sun, Apr 24, 2011 at 11:25:52PM +1000, Allan McRae wrote:
On 23/04/11 09:32, Dan McGee wrote:
Allan and I today, and Denis in the past, noticed some issues with having a shared public key database and locking that gpg wants to do when reading from it. Here is an interesting bit from the apt changelog:
apt (0.6.2) experimental; urgency=low * Provide apt-key with a secret keyring and a trustdb, even though we would never use them, because it blows up if it doesn't have them
From what I gather, they don't use the trustdb for the reasons we are seeing; instead it looks like they have another keyring named "trusted.gpg" and go forth with the assumption that everything in there is to be trusted.
Looking into this, I believe that we are hitting an entirely separate issue. The reason for a lack of trustdb in the Debian case appears to be more to do with keyring management that anything else.
The main issue here is that gpg(me) creates a lock file in the keyrings home directory whenever it uses a keyring. Our keyring directory only has write permissions for the root user and thus when pacman is not being run as root (such as the "pacman -Qip<pkg>" case), it can not create a lock file.
We can work around this by making the /etc/pacman.d/gnupg directory have 777 permissions. The {pubring,secring,trustdb},gpg files will still have only root write permissions so I guess this is safe as long as those files are created as part of the pacman package itself... Also, unless I am missing something even if other files are added in that directory by a user, they should not affect gpg. Still... 777 permissions on that directory sounds scary.
Eh? Giving a directory "777" permissions still allows arbitrary users to delete and subsequently re-create files with write permissions. So this might be a bad idea, here.
Ah crap... I knew there was something I was missing. 1777 permissions then. Allan
On Sun, Apr 24, 2011 at 8:25 AM, Allan McRae <allan@archlinux.org> wrote:
On 23/04/11 09:32, Dan McGee wrote:
Allan and I today, and Denis in the past, noticed some issues with having a shared public key database and locking that gpg wants to do when reading from it. Here is an interesting bit from the apt changelog:
apt (0.6.2) experimental; urgency=low * Provide apt-key with a secret keyring and a trustdb, even though we would never use them, because it blows up if it doesn't have them
From what I gather, they don't use the trustdb for the reasons we are
seeing; instead it looks like they have another keyring named "trusted.gpg" and go forth with the assumption that everything in there is to be trusted.
Looking into this, I believe that we are hitting an entirely separate issue. The reason for a lack of trustdb in the Debian case appears to be more to do with keyring management that anything else. Well sure...that was my point and what I gathered though- if you have a keyring that has keys you only trust, you don't need a trust DB, no?
The main issue here is that gpg(me) creates a lock file in the keyrings home directory whenever it uses a keyring. Our keyring directory only has write permissions for the root user and thus when pacman is not being run as root (such as the "pacman -Qip <pkg>" case), it can not create a lock file. Yes, totally understand. However, it only creates said lock file IF a
http://www.debian.org/doc/manuals/securing-debian-howto/ch7 Debian does not provide signed packages but provides a mechanism available since Debian 4.0 (codename etch) to check for downloaded package's integrity[52]. For more information, see Secure apt, Section 7.5.2. http://www.debian.org/doc/manuals/securing-debian-howto/ch7#s-apt-0.6 gpg is the tool used in secure apt to sign files and check their signatures. apt-key is a program that is used to manage a keyring of gpg keys for secure apt. The keyring is kept in the file /etc/apt/trusted.gpg (not to be confused with the related but not very interesting /etc/apt/trustdb.gpg). apt-key can be used to show the keys in the keyring, and to add or remove a key. trustdb has content
We can work around this by making the /etc/pacman.d/gnupg directory have 777 permissions. The {pubring,secring,trustdb},gpg files will still have only root write permissions so I guess this is safe as long as those files are created as part of the pacman package itself... Also, unless I am missing something even if other files are added in that directory by a user, they should not affect gpg. Still... 777 permissions on that directory sounds scary. This sounds scary and not good at all to me...
Anyway, doing this makes the signature validation with -Qip work for non-root users (using Dan's gpg branch WIP patches).
Note that GPG itself has an option not to do locking (with a big warning about that being bad...), and I thought maybe we could do that for the non-root usage case, but it looks like gpgme can not do that.
On Fri, Apr 29, 2011 at 5:11 PM, Dan McGee <dpmcgee@gmail.com> wrote:
On Sun, Apr 24, 2011 at 8:25 AM, Allan McRae <allan@archlinux.org> wrote:
The main issue here is that gpg(me) creates a lock file in the keyrings home directory whenever it uses a keyring. Our keyring directory only has write permissions for the root user and thus when pacman is not being run as root (such as the "pacman -Qip <pkg>" case), it can not create a lock file.
And now for our other "competition", yum. Here is how they work around this problem: http://yum.baseurl.org/gitweb?p=yum.git;a=commitdiff;h=3f0d169e7ee Also of interest is their auto key import deal: http://yum.baseurl.org/gitweb?p=yum.git;a=commitdiff;h=751146bf73d -Dan
participants (3)
-
Allan McRae
-
Dan McGee
-
Lukas Fleischer