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