Mailing List Archive

private-keys-v1.d and preserve-permissions
Hello,

I am working with Debian Stretch (9.13) and GPG 2.1.18.

The "private-keys-v1.d" directory has per default the permissions 700
(drwx------), but I need them to be 770 (drwxrwx---). I can change the
permissions ($ chmod 770 private-keys-v1.d) but after some time they are
be back to 700.

According to the documentation
(https://www.gnupg.org/documentation/manuals/gnupg/GPG-Esoteric-Options.html#GPG-Esoteric-Options)
there is an option "--preserve-permissions" with the description "Don't
change the permissions of a secret keyring back to user read/write
only." I assumed that is what I need and added this option as
"preserve-permissions\n" to the "gpg.conf" file.

But it is not working as expected. When I stop the gpg-agent ($ gpgconf
--kill gpg-agent) and trigger its restart ($ gpg -K), the permissions
are back to 700. (I also checked, that the gpg.conf file is in fact used.)

Where am I wrong here? Is the setting not what I need, or do I set it
incorrectly, or do I test it incorrectly?

And if the setting is not what I need, how can I prevent the permissions
for "private-keys-v1.d" from changing?

Regards,
Martin

_______________________________________________
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: private-keys-v1.d and preserve-permissions [ In reply to ]
On Wed, 9 Sep 2020 15:22, Martin Pätzold said:

> And if the setting is not what I need, how can I prevent the
> permissions for "private-keys-v1.d" from changing?

The --preserve-permissions is a gpg option and not one of gpg-agent. In
fact gpg does not known anything about private-keys-v1.d. And well, the
gpg option does nothing because gpg has no control over secret keys.

I will update the documentation to clarify that this is a dummy option.

Is there a special reason that you need to give group access to those
files?


Salam-Shalom,

Werner
Re: private-keys-v1.d and preserve-permissions [ In reply to ]
Hi,

I looked at the history and the reason for the described behaviour is
documented at https://dev.gnupg.org/T2312. I re-opened that bug.


Shalom-Salam,

Werner

--
Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.
Re: private-keys-v1.d and preserve-permissions [ In reply to ]
On Wed, 9 Sep 2020 19:37, Werner Koch said:

> I looked at the history and the reason for the described behaviour is
> documented at https://dev.gnupg.org/T2312. I re-opened that bug.

Fixed in master and 2.2 see the ticket above for the patch.

Salam-Shalom,

Werner

--
Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.
Re: private-keys-v1.d and preserve-permissions [ In reply to ]
Thanks for the clarification and the patch.

> Is there a special reason that you need to give group access to those
> files?

Yes, we have some period tasks that are handled by Celery. Celery has
its own user on the system and this user needs at least read access to
the keys, therefore we had to extend the permissions for the
"private-keys-v1.d" directory to group access.

Regards,
Martin

_______________________________________________
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: private-keys-v1.d and preserve-permissions [ In reply to ]
On 10/09/2020 09:34, Martin Pätzold wrote:
> Yes, we have some period tasks that are handled by Celery. Celery has
> its own user on the system and this user needs at least read access to
> the keys, therefore we had to extend the permissions for the
> "private-keys-v1.d" directory to group access.

Long shot: does your system support ACLs?

--
Andrew Gallagher
Re: private-keys-v1.d and preserve-permissions [ In reply to ]
>> Yes, we have some period tasks that are handled by Celery. Celery has
>> its own user on the system and this user needs at least read access to
>> the keys, therefore we had to extend the permissions for the
>> "private-keys-v1.d" directory to group access.
>
> Long shot: does your system support ACLs?

Using ACL would be possible, but we are reluctant to do so, since it
adds a second permissions layer that is only visible if you actively
look for it.

Regards,
Martin

_______________________________________________
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: private-keys-v1.d and preserve-permissions [ In reply to ]
On Thu, 10 Sep 2020 11:13:34 +0200, Martin Pätzold stated:
> >> Yes, we have some period tasks that are handled by Celery. Celery
> >> has its own user on the system and this user needs at least read
> >> access to the keys, therefore we had to extend the permissions for
> >> the "private-keys-v1.d" directory to group access.
> >
> > Long shot: does your system support ACLs?
>
>Using ACL would be possible, but we are reluctant to do so, since it
>adds a second permissions layer that is only visible if you actively
>look for it.

Perhaps I am not understanding this correctly, but wouldn't that be a
good thing?

--
Jerry
Re: private-keys-v1.d and preserve-permissions [ In reply to ]
>>> Long shot: does your system support ACLs?
>>
>> Using ACL would be possible, but we are reluctant to do so, since it
>> adds a second permissions layer that is only visible if you actively
>> look for it.
>
> Perhaps I am not understanding this correctly, but wouldn't that be a
> good thing?

Not from a maintenance perspective. This would be the only exception in
permission handling across all of our platforms and it is not
immediately visible. Six or twelf months from now we may not remember
this exception and may lose a lot of time debugging if we don't look
into the documentation early enough.

Regards,
Martin

_______________________________________________
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: private-keys-v1.d and preserve-permissions [ In reply to ]
On Thu, 10 Sep 2020 10:34, Martin Pätzold said:

> the keys, therefore we had to extend the permissions for the
> "private-keys-v1.d" directory to group access.

I see. Just a hint: You may use the remote socket feature to run
gpg-agent under a different account. It might take a bit of effort to
get the details right and make the system robust enough.


Salam-Shalom,

Werner

--
Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.