On Tue, May 24, 2011 at 07:37:29PM +0200, Lennart Poettering wrote: > On Tue, 24.05.11 17:02, Roger Leigh ([email protected]) 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.
No. Some programs were, in the absence of /run, using /dev/.xxx or /dev/shm/xxx in place of /run/xxx (examples: udev, mdadm, initramfs-tools). These will now be moved to /run--they were violating the FHS. This is completely independent from actual POSIX SHM/SEM usage. > > 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? It's ephemeral data which requires the same lifetime guarantees as other data on /run. Shared memory is not a device, and does not belong under /dev--it's not actually FHS compliant AFAICT. > /dev/shm is user data. You are contradicting yourself. No. We mount a *separate* tmpfs on /run/shm, so /run remains writable only by the system. If the admin so chooses, it is, however, possible for a single tmpfs to be used for all subdirectories of /run. We also support /run/lock being a separate tmpfs, and if you configured it, you could also have /tmp symlinked under /run. (I'm not suggesting that it's advisable, merely possible.) This allows the admin to make the tradeoff between security (separate mounts with separate perms and limits) or flexibility (everything on a single tmpfs). We default to having it secure. We would be obliged to have /run/user as a separate mount should it be required in Debian, in the same manner as above. > > 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. I assure you that I have given these issues serious thought. I would appreciate it if you could keep the conversation focussed on technical issues. Thanks. If you would care to explain exactly why /tmp is unsuitable in detail, to correct any oversight on my part, that would be appreciated. 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
