[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