On Mon, May 23, 2011 at 02:30:54PM +0200, Lennart Poettering wrote: > 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.
While having this deficiency fixed would be ideal, we will still need to cope with older kernels even after it is fixed. > > > > 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.) Having some concrete information about what different distributions do would be useful here. And I sincerely hope that Debian will not "fix" this, given the breakage that automated cleaning causes. > > - /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. I have read it. In the context of the FHS, I don't think the text of the spec means much. It's fine to say "must", but if a session is killed unexpectedly it can still fail to clean up despite what the spec states, and this needs to be considered. > > 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. Perhaps. But in the context of the FHS, how a particular init system may or may not handle cleanup is not that useful--the FHS needs to be uniform across all init systems and platforms, and this isn't a requirement that can be enforced nor guaranteed. > > 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. I think the issues you highlight above could be summarised as follows: "cleanup of /tmp causes massive problems for applications using /tmp". This really does sound like a "Doctor, it hurts when I do this" scenario, and the answer is probably "don't do that then". It's not at all surprising that removing in-use data causes collateral damage, and it's really not something that the FHS needs to, or can be expected to deal with. Why should applications need to have massively complex code to workaround cleanup of /tmp, when simply /not/ cleaning /tmp is the simple solution? This isn't exactly a new problem. Aggressive /tmp cleanup on big Sun/Solaris systems was causing me big problems 15 years ago, and it's still just as bad today. Please note that the FHS makes no mention of cleaning /tmp after startup; it's a site-specific issue left to the admin. As I said before: if you choose to enable automated cleanup of /tmp, you do so in the full knowledge that it will cause breakage. Expecting that applications should explicitly cater for such is unrealistic. While in theory this could happen to any program at any point in time on a multiuser, multitasking system as another process makes changes to the filesystem, most programs would be expected to notice as system calls fail and bail out appropriately as would be the case for file operations in any other part of the filesystem hierarchy. Complex and fragile workarounds are not a good idea, especially given that cleanup can introduce "interesting" security issues which are entirely absent sans cleanup. > > 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. As I said above, we need to cater for past and current kernels irrespective of newer kernels fixing things. And we could well be running on non-Linux kernels without tmpfs support as well. While the various BSDs chose not to participate in the FHS, Debian does also run on the FreeBSD and Hurd kernels, and I am taking their needs into account as well when considering what Debian wants from the FHS. As mentioned in other mails: /run /should/ be on a tmpfs, but this is *not* guaranteed. It could be just a regular filesystem. In consequence, we can not provide the guarantees you desire, even on plain Linux kernels--consider embedded systems with low memory and no swap where a tmpfs is too expensive, for example. > > > I am not sure what session-specific directories would achieve, but > > > 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). The FHS shouldn't really be standardising usage based upon current limitations in the GNOME desktop session and login handling. And the same applies to ridiculous limitations in applications like firefox which refuse to permit multiple instances. Other desktops and applications do not have these curious limitations. You might well think that it's "pointless" to fix such limitations. However, the FHS has a wider scope than this; a "session" might not even necessarily relate to an "X session". If set up by PAM, it might be tied to any other PAM service, including console and SSH logins. The various "-agent" processes are usually tied to a single login session, and you might well want per-session instances (the system I'm writing this mail on has ssh-agents tied to separate screen sessions). While the XDG might mandate a certain usage for /run/user for XDG-compliant applications, the location as standardised in the FHS may well have users which are FHS compliant yet not XDG compliant. What was already concluded as being acceptable to the XDG may not be acceptable to the FHS--please do bear in mind that it has a rather wider scope. 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
