On Sat, Jul 23, 2011 at 11:03:48PM +0200, Tollef Fog Heen wrote: > ]] Roger Leigh > > | /run/user is created by systemd. This contains within it directories > | owned by logged in users e.g. /run/user/rleigh in my case, and the > | environment variable XDG_RUNTIME_DIR is set to this location. > > This only happens if you use libpam-systemd, doesn't it?
Ah, yes. > | There are a few problems with this: > | > | 1) Any user can now trivially DoS the system by filling up /run. > | 2) The directory is a session-specific directory, and this only > | permits one login session at once, at least if one wants to have > | per-session state, rather than shared between sessions. > > Agreed on those counts, though if the admin is worried about the former, > it's trivial to mount a size-constrained tmpfs on top /run/user. If we do continue to use this path, I think we should be doing that by default, as for the other user-writable filesystems (lock and shm). We would need to have a sensible default size limit for it as well, as for the existing tmpfs filesystems. > | 3) /tmp is already suitable for this purpose: systemd can use > | /tmp/user in exactly the same way. > > /tmp is allowed to loose information more easily than /run, though. True. While this would be the case if the admin has tmpreaper or its equivalent installed, this is not the default on Debian. And if we do use /tmp/user, we can update tmpreaper and its equivalents to blacklist this path so it isn't touched. This would provide the same guarantees as /run/user would. I would, however, argue that automated cleaning of /tmp under any circumstances is fundamentally broken. It breaks all the expectations of even well-written programs. It will always eventually cause dataloss, and distributions like Fedora that enable it by default have been badly burned by it on multiple occasions. Software can not work around the fact that a file may be deleted at any point. The solution is not to move to an alternative filesystem location, it's to not have a broken setup in the first place! When tons of stale files get left in /run/user, it will be the next place to get cleaned, and we'll have the same problem all over again! > | While /tmp isn't necessarily a tmpfs like /run, please note that: > | 1) /run isn't necessarily a tmpfs either > | 2) /tmp can be made a tmpfs > | 3) systemd can easily create an empty /tmp/user at startup; it can > | even remove the directory tree if present from a previous boot > | to ensure it's clean from the start. > > Or the admin can create a symlink from /run/user to /tmp/user and make > sure the latter exists themselves. > > I'm not sure I'm going to do anything about this bug since I don't > really agree with it being a bug to begin with and if an admin wants a > different behaviour, that's easy enough to set up. I think the outstanding question here is whether users should have write access to /run. Given that it is /var/run moved to /run, and this would not be permitted use of /var/run, I don't think it's appropriate for /run either. The FHS draft also doesn't make any changes to the purpose of /run, it's just moved from /var/run. We definitely have exceptions to this: /run/shm and /run/lock, and these are kept separate for that reason. And WRT /run/lock, there was some talk of restricting that as well, which would remove the requirement for a separate mount. I am, however, concerned about the use of /run for things which are already catered for by other established parts of the filesystem hierarchy, and this definitely includes /run/user. /run/lock is definitely a system location, for system-wide lockfiles. /run/shm is again for system-wide shared memory. /run/user is for user-private session data, and it's even limited at that (to a single session, for unknown reasons). 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
