Re: private-keys-v1.d and preserve-permissions
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. signature.asc Description: PGP signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: private-keys-v1.d and preserve-permissions
>>> 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
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 pgpAl6OEnu7lN.pgp Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: private-keys-v1.d and preserve-permissions
>> 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
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 signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: private-keys-v1.d and preserve-permissions
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
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. signature.asc Description: PGP signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: private-keys-v1.d and preserve-permissions
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. signature.asc Description: PGP signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: private-keys-v1.d and preserve-permissions
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 signature.asc Description: PGP signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
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
