[pacman-dev] trustdb locking issues and snippets from the apt changelog

[Allan McRae]

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