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

Werner Koch wk at gnupg.org
Fri Oct 7 08:35:31 CEST 2016


On Thu,  6 Oct 2016 11:17, justus at g10code.com said:

> Oh?  What about all the people not using systemd?

The problem here is that Debian or systemd change long existing
properties of the /var partition.  Right, they now call it /run but it
is nevertheless symlinked from /var/run.

/var has a persistent directory structure for good reasons.  It is also
the most important partition for regular system backup.  All things
which are subject to regular change are stored under /var but entire
directory structures should not be removed at init time or even logout
time.  What needs to be removed are stale lock files and PID stuff but
only at the init time when they are not anymore valid. 

Some OSes take a simple approach to the latter by using a tmpfs for
/var/run.  However, the directory structure should in general be saved
over shutdown/init because it carries important permission settings.

> 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

That happens only due to the defects mention above.  What needs to be
fixed is to save/restore the layout of /var/run during shutdown/init and
only selectively unlink files or directories which are invalid after
shutdown.  

The other option would be to let GnuPG create the /var/run/user/UID
directory on the fly.  However this requires configuration of userv and
complicates the GnuPG code for no good reason.  The session startup code
could create that directory.  GnuPG will already creates the gnupg
subdirectory iff /var/run/user/UID exists.


Salam-Shalom,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 162 bytes
Desc: not available
URL: </pipermail/attachments/20161007/9712f858/attachment.sig>


More information about the Gnupg-devel mailing list