On Mon, 23.05.11 10:35, Roger Leigh ([email protected]) wrote: > On Mon, May 23, 2011 at 01:10:32AM +0200, Richard Hartmann wrote: > > On Sun, May 22, 2011 at 22:35, Roger Leigh <[email protected]> wrote: > > > > > Do we want to allow users to create files under /run, or reserve it > > > solely for system use? > > > > No, that is why I wanted user-specific directories. > > From the POV of the system being guaranteed to be able to create > files in /run e.g. when starting a service, or to be able to continue > to append to datafiles (samba), you do not want the user to be able > to fill up that filesystem. It's especially important here because > there's no 5% "reserved" blocks like on ext, so any user could, either > accidentally or deliberately, break the entire system. I really don't > want that, and this does need to be considered lest our systems > become vulerable to simple local DoS.
This is a general problem by which /dev/shm, /tmp and /run/user suffer. It's on the todo list to fix this in the kernel by providing something quota-like (for example an rlimit) on tmpfs. > > > What makes /tmp unsuitable for this purpose? It's already possible > > > to securely create directories owned by the user there, and these > > > runtime files are, by definition, temporary. > > > > /tmp will most likely be cleared out from time to time. /run is guaranteed > > to. > > I don't agree with either of these assertions. > > - /tmp isn't cleaned by default. It is on most distributions I think (maybe not Debian though, but they should fix that.) > - /run/user won't be cleaned by default either. Please read the XDG_RUNTIME_DIR spec. Its a *MUST* that this directory is removed after a complete logout. > However, consider that on a busy or long running system that you'll > end up with stray session directories under /run/user as well. That would be a weakness in your implementation. On a systemd system this doesn't happen. > At that point you'll be in the same situation as /tmp, and you'll > need to clean them *both*... In consequence, I don't think that /run > is a better choice than /tmp. I think PulsedAudio is the only application that ever got it right placing a socket in /tmp. And the code for that is massive. I am not sure you understand the complexity of this. i.e. You need to create a random directory in /tmp, and then add a symlink in $HOME to that dir, so that you can access it under a well-defined name. The complexity now is added on top of that in that this symlink needs to include a machine id of some kind to not break NFS, and you need to ensure that the directory in /tmp is really yours in case /tmp was cleaned up since you created the dir in it. That is just crazy. In fact the entirety of /tmp is just a gigantic fuckup. The advantages of /run/user/$USER is the guaranteed cleanup and private namespace, which makes it very easy to write safe code that doesn't pollute the file systemd over long. > If we do go this route, I'll have to make /run/user an additional > tmpfs mount for Debian to make it safe. No, you shouldn't. Just wait until the kernel is fixed, or even better: fix it yourself. Don't try to tape over problems in userspace that should fixed in kernelspace. > > I am not sure what session-specific directories would achieve, but > > > > /run/user/$USER/session.d/XXXXXXXXXX > > or > > /run/user/$USER/sessions/XXXXXXXXXX > > or > > /run/user/$USER/session/XXXXXXXXXX > > > > could be created easily. > > > > $XDG_RUNTIME_SESSION_DIR > > > > could hold the link to it. I am still not sure what its use would be, > > though. > > Its purpose would be to keep each session separate. We don't limit > users to one login session, so why would we want to share the session > state between multiple sessions? If sharing, it also brings with it > the problem of who cleans up the session directory, and when; if they > are separate, it's clear who has that responsibility (the initiating > process), and when it should be done (end of session). If services are per-session then they should simply include a session identifier in the files/sockets they create in /run/user. I think putting an emphasis on multiple sessions per user is wrong though. Most terminal user services are per-user (not per-session) anyway (i.e. gpg-agent, ssh-agent, ...). And desktops like GNOME (or the popular apps, like firefox, ...) cannot really cope with multiple simultaneous graphical logins anyway. And fixing that is kinda pointless. (Yeah, I am sure you disagree with that and believe that multiple X11 sessions is something we totally should support, but everybody who worked on the XDG stuff was convinced otherwise, and I am not going to reopen that discussion again). Lennart -- Lennart Poettering - Red Hat, Inc. _______________________________________________ fhs-discuss mailing list [email protected] https://lists.linux-foundation.org/mailman/listinfo/fhs-discuss
