[fhs-discuss] user-specific directories in /run

Lennart Poettering lennart at poettering.net
Tue May 24 10:37:29 PDT 2011


On Tue, 24.05.11 17:02, Roger Leigh (rleigh at codelibre.net) wrote:

> /run as it stands was a relatively uncontroversial change.  It's
> just moving /var/run to /run and making it available from the
> early initramfs onwards.  /var/run in Debian was already configurable
> as a tmpfs, so it was a simple migration and was already entirely
> supported by all packages.  The other migrations of /var/lock,
> /lib/init/rw and /dev/.* and /dev/shm/* to /run were of data which

/dev/shm in /run? What's the point of that? That's a broken Debianism.

> already /logically belonged/ under /run but were stored elsewhere, and
> were equally uncontroversial--we've had patches to implement /run
> since 2003!  (http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=186892)

Why does /dev/shm belong under /run?

> Storing user data under /run *is* controversial, and I object strongly
> to it.  It is a big departure from existing practice where the earlier

Dude, /dev/shm is user data. You are contradicting yourself.

> changes *were not*, and it brings with it a host of issues as mentioned
> in other mails.  /tmp exists specifically for this purpose, and while
> you've pointed out that problems exist with /tmp, these are entirely
> self-inflicted and are easily resolvable.

/tmp exists as place where mkstemps() and mkdtemp() can be used on. This
should be the only API for /tmp. Everything else is problematic for
security reasons and that's why we should *never* place sockets there.

Applications placing sockets uner /tmp are broken applications.

> /run is currently restricted to *system* state, and there are good

Nope, not on Fedora, not on Debian. You moved /dev/shm there and all
systemd systems have /run/user there.

/run is for runtime state. Hence the name.

> reasons for that.  User session state belongs under /tmp; it's no
> more special than any other temporary data created by the user.  Note
> that cleanup programs such as tmpreaper can be configured to exclude
> certain patterns, so it's not like this isn't a simply resolvable
> issue--just ensure that session state doesn't get cleaned up and your
> problem is fixed.

Before you make fantastic claims like this you should make your
homework. If you had you'd know how fucked /tmp is. And why /run/user
makes so much sense.

The namespacing problem is not fixable in /tmp. That's why you should
give up on it. Please make a serous try in understanding that problem.

Lennart

-- 
Lennart Poettering - Red Hat, Inc.


More information about the fhs-discuss mailing list