[Pkg-sysvinit-devel] Bug#637856: /run/lock should be owned by uucp

Roger Leigh rleigh at codelibre.net
Mon Aug 15 09:15:29 UTC 2011


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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://lists.alioth.debian.org/pipermail/pkg-sysvinit-devel/attachments/20110815/c3f3bcb3/attachment.pgp>


More information about the Pkg-sysvinit-devel mailing list