Re: Introduction of a lock group
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. signature.asc Description: Digital signature
Re: Introduction of a lock group
On Mon, Aug 15, 2011 at 07:36:26PM +0200, Iustin Pop wrote: On Mon, Aug 15, 2011 at 06:00:50PM +0100, Roger Leigh wrote: On Mon, Aug 15, 2011 at 05:35:54PM +0100, Colin Watson wrote: On Mon, Aug 15, 2011 at 04:11:49PM +0100, Roger Leigh wrote: Are these any other downsides we need to consider? One issue is the existence of badly broken programs³, which make stupid assumptions about lockfiles. What about programs that need to write lock files which are already setgid something else? I don't have an example off the top of my head, but it would surprise me if there were none of these. IIRC Fedora have a setgid lock locking helper for this, which lockdev uses internally. I'd need to check the details on a Fedora VM. IIRC it checks if you have write perms on the device being locked, and so individual programs don't need to be setgid lock unless they are not using liblockdev. The use of an external helper means this is significantly slower than an open(…, O_CREAT) + flock(). While this works for some workloads, it doesn't for all. This helper is basically restricted to device locking, in particular serial devices (minicom, uucp, wvdial etc.). I can't off the top of my head think of a scenario where this would cause problems. It's also basically a temporary solution until these programs can be patched to use lockdev, and/or for lockdev to support proper device locking with fcntl. As my other question was: /var/lock (or /run/lock) was a good solution for transient, cheap locks for coordination between some cooperative programs. It would be ideal if we have a recipe for this after the permissions change. This should hopefully have been addressed in my other reply WRT tmpfiles.d, which permits this providing you have a directory writable by the user/group in question. Access for normal users is however no longer possible--they would need to use somewhere they have write access, e.g. /tmp. 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
Re: Introduction of a lock group
[Roger Leigh] 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. Makes sense that tmpfiles.d comes from systemd, if he's trying to get away from shell scripts. But for those who think it's annoying to have to put 3 separate steps in your init script 'start' section (mkdir -p, chown, chmod), I'd like to point out that you may as well just use install -d, and do it all in one step. Not to say we _can't_ adopt the tmpfiles.d approach, just that doing this sort of thing inside your init script need not be painful. -- Peter Samuelson | org-tld!p12n!peter | http://p12n.org/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110816161905.gb7...@p12n.org
Re: Introduction of a lock group
On Tue, 16 Aug 2011 at 11:19:05 -0500, Peter Samuelson wrote: But for those who think it's annoying to have to put 3 separate steps in your init script 'start' section (mkdir -p, chown, chmod), I'd like to point out that you may as well just use install -d, and do it all in one step. ... as long as /usr is mounted (Required-Start: $remote_fs). That's true for the majority of init scripts anyway, but something to be aware of. S -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110816170842.ga26...@reptile.pseudorandom.co.uk
Re: Introduction of a lock group
On Tue, Aug 16, 2011 at 11:19:05AM -0500, Peter Samuelson wrote: Makes sense that tmpfiles.d comes from systemd, if he's trying to get away from shell scripts. But for those who think it's annoying to have to put 3 separate steps in your init script 'start' section (mkdir -p, chown, chmod), I'd like to point out that you may as well just use install -d, and do it all in one step. Provided your init script guaranteeably runs after /usr is mounted, yes. -- Colin Watson [cjwat...@debian.org] -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110816172553.ga18...@riva.dynamic.greenend.org.uk
Introduction of a lock group
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 This mail is to discuss these issues: 1) Addition of a lock group as a system group This is a trivial change but requires approval. 2) Alignment of /var/lock with Fedora This will require patching of lockdev (should already be in git). It would also require programs patching to use the new paths if not using lockdev. Are these any other downsides we need to consider? One issue is the existence of badly broken programs³, which make stupid assumptions about lockfiles. ¹http://lists.freedesktop.org/archives/systemd-devel/2011-April/001828.html ²https://bugzilla.redhat.com/show_bug.cgi?id=581884 ³http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=637856 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
Re: Introduction of a lock group
* Roger Leigh (rle...@codelibre.net) [110815 17:12]: Are these any other downsides we need to consider? One issue is the existence of badly broken programs³, which make stupid assumptions about lockfiles. This will break all existing programms on an partial upgrades. There are three ways to deal with it: 1. Don't adjust permissions on existing systems 2. Add Breaks to all relevant programs 3. Adjust permissions on existing systems one release later Andi -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110815153144.ga15...@mails.so.argh.org
Re: Introduction of a lock group
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 Hi, 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? thanks, iustin signature.asc Description: Digital signature
Re: Introduction of a lock group
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? I'll have to inspect what Fedora is doing more closely to give you a definitive answer. If you always start the daemon as root, it can continue to use /var/lock without trouble if it does its file handling before changing to a less privileged user. Creating a daemon-specific subdirectory is also fine, though you could nowadays also use /run/daemon for daemon- specific things, including locks. Or even /var/lib/daemon if they should persist. In some respects, /var/lock is a bit of an anachronism; /var/run exists for pidfiles, and actual UUCP-style lockfiles are badly broken--we should be moving to direct device locks. If it's a daemon-specific lock, rather than one with system-wide effects such as device locking, it probably doesn't belong under /var/lock. If we eliminate device locking using lockfiles, what's left to go under /var/lock? [I don't always agree with Lennart Poettering, but his views on /var/lock and device lockfiles being obsolete are, I think, entirely correct.] 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
Re: Introduction of a lock group
On Mon, Aug 15, 2011 at 04:11:49PM +0100, Roger Leigh wrote: 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 This mail is to discuss these issues: 1) Addition of a lock group as a system group This is a trivial change but requires approval. Would such a system group need to be statically allocated, or could it be dynamically allocated? (Generally the latter is better if possible, of course - I haven't had to add a global static group for years, and I like it that way - but one might wish to consider things like bind mounts of /run/lock into chroots, which would no longer be NSS-agnostic.) Are these any other downsides we need to consider? One issue is the existence of badly broken programs³, which make stupid assumptions about lockfiles. What about programs that need to write lock files which are already setgid something else? I don't have an example off the top of my head, but it would surprise me if there were none of these. -- Colin Watson [cjwat...@debian.org] -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110815163554.ga3...@riva.dynamic.greenend.org.uk
Re: Introduction of a lock group
On Mon, Aug 15, 2011 at 05:35:54PM +0100, Colin Watson wrote: On Mon, Aug 15, 2011 at 04:11:49PM +0100, Roger Leigh wrote: 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 This mail is to discuss these issues: 1) Addition of a lock group as a system group This is a trivial change but requires approval. Would such a system group need to be statically allocated, or could it be dynamically allocated? (Generally the latter is better if possible, of course - I haven't had to add a global static group for years, and I like it that way - but one might wish to consider things like bind mounts of /run/lock into chroots, which would no longer be NSS-agnostic.) I was initially thinking that static would be the best approach. But if the general consensus is that /var/lock/lockdev etc. aren't going to be around in the long term, then dynamic would be better-- we can then switch lockdev and other UUCP-style lock users to direct locking and remove it. There is compatibility with ancient UUCP software to consider though, but how important is that? They have had years to switch to using liblockdev. Are these any other downsides we need to consider? One issue is the existence of badly broken programs³, which make stupid assumptions about lockfiles. What about programs that need to write lock files which are already setgid something else? I don't have an example off the top of my head, but it would surprise me if there were none of these. IIRC Fedora have a setgid lock locking helper for this, which lockdev uses internally. I'd need to check the details on a Fedora VM. IIRC it checks if you have write perms on the device being locked, and so individual programs don't need to be setgid lock unless they are not using liblockdev. 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
Re: Introduction of a lock group
On Mon, Aug 15, 2011 at 06:00:50PM +0100, Roger Leigh wrote: On Mon, Aug 15, 2011 at 05:35:54PM +0100, Colin Watson wrote: On Mon, Aug 15, 2011 at 04:11:49PM +0100, Roger Leigh wrote: Are these any other downsides we need to consider? One issue is the existence of badly broken programs³, which make stupid assumptions about lockfiles. What about programs that need to write lock files which are already setgid something else? I don't have an example off the top of my head, but it would surprise me if there were none of these. IIRC Fedora have a setgid lock locking helper for this, which lockdev uses internally. I'd need to check the details on a Fedora VM. IIRC it checks if you have write perms on the device being locked, and so individual programs don't need to be setgid lock unless they are not using liblockdev. The use of an external helper means this is significantly slower than an open(…, O_CREAT) + flock(). While this works for some workloads, it doesn't for all. As my other question was: /var/lock (or /run/lock) was a good solution for transient, cheap locks for coordination between some cooperative programs. It would be ideal if we have a recipe for this after the permissions change. thanks, iustin signature.asc Description: Digital signature
