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

[Joerg Dorchain]

On Mon, Aug 15, 2011 at 10:15:29AM +0100, Roger Leigh wrote:
> 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

Well, there are issues with setuid()-binaries that need to do
their own access checks. A more common example would be the
sendmail binary.

> 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:

Yes, for a certain point of view you can argue that the
application is broken and that this is just a bad excuse for a
workaround of closed source sofware.
On the other hand, following the first paradigma of operations
("It has to work") this is the easiest place for a change that
makes it work with almost no side effects.
IMHO it would be a nice little feature of debian to be able to
cope with commercial software of certain quality.
> 
> 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.

As uucp is traditionally (yes, that means it is more than a
decade old and nobody but but long and greyhaired grandfathers
remember how it came to that) the user who uses lockfiles.
Specifically, that is what I need for my application to work.
I don't mind to have this configurable somewhere, e.g. yet
another rcS-variable would still be better than editing the
init.d script directly.
> 
> > 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.

No problem with that. IIRC this is even supported by the rxtx
library my questionable binary uses. This would also separate the
locking functionally from the rest of the uucp stuff. setgid lock
would not even be necessary, just having lock amongst the
additional groups of the calling user would be sufficient.
I would still propose mode 3775, though.

On the other hand, uucp style lockfiles are typically used for
accessing devices owned by the dialout group.

Bye,

Joerg
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 267 bytes
Desc: Digital signature
URL: <http://lists.alioth.debian.org/pipermail/pkg-sysvinit-devel/attachments/20110815/e92c6633/attachment.pgp>