On Mon, Aug 15, 2011 at 06:03:59PM +0200, Iustin Pop wrote: > On Mon, Aug 15, 2011 at 04:11:49PM +0100, Roger Leigh wrote: > > Hi folks, > > > > Fedora has moved to having /var/lock (now /run/lock) owned by > > root:lock 0775 rather than root:root 01777. This has the advantage > > of making a system directory writable only by root or setgid lock > > programs, rather than the whole world. However, due to the > > potential for privilege escalation¹² it may be desirable to adopt > > what has been done subsequently in Fedora: > > /var/lock root:root 0755 > > /var/lock/lockdev root:lock 0775 > > /var/lock/subsys root:root 0755 > > If /var/lock won't be 1777 anymore, where should then applications store > application-specific lock files (e.g. synchronisation between daemons) > if they can't/won't run as setgid lock? > > Is the intention that the init script creates a /var/lock/$NAME > directory, chgrp's it to the right GIDs and only then start the daemons? This is how Fedora currently does it: Packages store their data in /var/lock/subsys/$package and this is created using /etc/tmpfiles.d. Packages can provide /etc/tmpfiles.d/$package and have a dpkg trigger or script e.g. update-tmpfiles create the missing directories. They would also be created at boot time. The tmpfiles.d file format specifies the name, ownership and permissions, which would allow daemon-specific ownership of their directories. tmpfiles.d comes from systemd, but we could adopt the concept without systemd being involved. If we didn't adopt tmpfiles.d, it would be the responsibility of the init script to create the necessary directories. I'm not entirely sure of the rationale for using /var/lock/subsys/$package rather than just using /var/lock/$package, which seems rather redundant IMO. 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.
Attachment:
signature.asc
Description: Digital signature