permissions required on /run/user/<uid>/gnupg

Justus Winter justus at g10code.com
Thu Oct 6 16:55:28 CEST 2016


Daniel Kahn Gillmor <dkg at fifthhorseman.net> writes:

> On Thu 2016-10-06 05:17:57 -0400, Justus Winter wrote:
>> Daniel Kahn Gillmor <dkg at fifthhorseman.net> writes:
>>
>>>> I fact, would like to entirely get rid of sockets in the homedir.  We
>>>> still need them for compatibility reasons but in the long term they
>>>> should go away.
>>>
>>> I'd love for them to go away as well!
>>
>> Oh?  What about all the people not using systemd?
>
> there's nothing that makes /run/user/<uid>/ systemd-specific.

... other than the fact that only systemd creates these directories.

> having an
> ephemeral chunk of the local filesystem that only your user can write to
> that *isn't* your homedir is useful for lots of reasons, not least of
> which are:

I understand, and I don't necessarily disagree with the features/changes
that systemd brings.  I have a problem with how they do it.  The
systemd/Linux crowd keeps making up interfaces.  They no longer need to
care about compatibility, anyone who wants to be compatible has to do
whatever systemd/Linux happens to do.

> If your operating system supports ephemeral, in-ram filesystems (An OS
> with the Linux kernel would call it "tmpfs", i dunno what it's called on
> other kernels), why *not* have such a mountpoint?

My operating system (Debian/Linux) happens to use this "tmpfs" feature
to provide an ephemeral /run without systemd, and has been for years ;)

> On the Linux kernel since version 2.2, we do have another such option,
> which would be to use the abstract sockets namespace, but that would
> require an entirely different permissions model, and would be a chunk of
> non-portable code.

No standardization for 17 years?  Yes, that sounds like a Linux
interface :/

>> Fwiw, I do not like that GnuPG automagically uses /run/users/X if it
>> exists, because everytime I accidentally install some package that pulls
>> in the systemd component that creates these directories, my gnupg setup
>> breaks.  Yes, it is my fault for expecting the sockets to be created in
>> ~/.gnupg, and yes, there is gpgconf that I should ask instead, but I
>> still consider it very surprising that installing a seemingly unrelated
>> package changes GnuPGs behavior like that.
>
> I agree with you that this behavior change is frustrating.  You can
> avoid the behavior change by just keeping /run/user/<uid>/ around in
> perpetuity ;)

Well, with /run being a tmpfs it is doable, but not trivial.


Cheers,
Justus
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 454 bytes
Desc: not available
URL: </pipermail/attachments/20161006/eccd2767/attachment.sig>


More information about the Gnupg-devel mailing list