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
>>> 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?
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
>> 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
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
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
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
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
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.
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.
10 matches
Mail list logo
