On Mon, May 23, 2011 at 02:42:03PM +0200, Lennart Poettering wrote: > On Mon, 23.05.11 10:17, Roger Leigh ([email protected]) wrote: > > > > > Do we want to allow users to create files under /run, or reserve it > > > > solely for system use? Right now, on Debian, it's not user-writable, > > > > with the exception of /run/lock (which can be a separate tmpfs mount, > > > > and we're looking at adding a lock group like other distros use to make > > > > this not globally writable) and /run/shm (which again is a separate > > > > tmpfs). > > > > > > Dude, you want to weaken the access restrictions on /run? Uh, no! If we > > > did that then everybody could just go there are and create /run/dbus and > > > subsequently D-Bus couldn't be started anymore. > > > > Having /run/user/$user writable by the user does not imply having /run > > writable by the user in any case (other than indirectly via DoS using > > all blocks/inodes). But in general, I think that having any part of > > /run user-writable is a legitimate concern--this wasn't part of its > > original remit, and it /does/ have implications that need careful > > consideration. > > Well, I certainly always had in mind creating /run/user, when we pushed > for /run.
Well, it certainly wasn't in *our* minds. /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 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) Storing user data under /run *is* controversial, and I object strongly to it. It is a big departure from existing practice where the earlier 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. /run is currently restricted to *system* state, and there are good 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. Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linux http://people.debian.org/~rleigh/ `. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/ `- GPG Public Key: 0x25BFB848 Please GPG sign your mail.
signature.asc
Description: Digital signature
_______________________________________________ fhs-discuss mailing list [email protected] https://lists.linux-foundation.org/mailman/listinfo/fhs-discuss
