On Mon, Aug 15, 2011 at 09:43:12AM +0200, Joerg Dorchain wrote: > there are programs that stat() /var/lock to test permissions > instead of actually trying to create lockfiles, the java rxtx > library for example. Before making this symlink to the /run/lock > tmpfs, ownership was preserved on harddisk.
I think the check is broken. They should just create the lockfile and deal with failure as and when it occurs. This use of stat(2) is always broken on a multiuser system in any case, because there's always a window between doing the check and creating the file during which the ownership/permissions could change. Regarding the ownership change (I assume here you changed it from root:root to root:uucp?), this has never been supported. And in any case, /run/lock and /var/lock are writable by anyone at present--the ownership should not matter: % ls -ld /run/lock drwxrwxrwt 3 root root 100 Aug 15 08:37 /run/lock % ls -ld /var/lock lrwxrwxrwx 1 root root 9 May 13 17:14 /var/lock -> /run/lock > A simple chgrp uucp /run/lock || true after creation/mounting of > /run/lock solves this and does not hurt programmes just trying to > write the lockfile. Why uucp? As shown above, the user and group owning the directory should not matter--it's globally writable and has the sticky-bit set. > A more general apporach is also welcome. We have been discussing moving to having a "lock" group as used by other distributions, but this hasn't happened yet. /run/lock would then be run:lock 02775 I think. Programs creating lockfiles would then need to be running/started as root or setgid lock. 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