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

[Roger Leigh]

On Mon, Aug 15, 2011 at 12:45:59PM +0200, Joerg Dorchain wrote:
> 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.

I'm not sure I follow.  A stat(2) on a symlink is equivalent to a
stat(2) on the pointed-to object, unless you use lstat(2).  Since
the directory is world-writable, any access checks will always succeed.
The introduction of the /var/lock->/var/run symlink will not change
the behaviour of stat(2).

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

I don't think this is an issue restricted to Debian--it is presumably
already broken on most other distributions as well?  This isn't a
recent change, or a change made in isolation.  AFAICT it was made
for FHS compliance reasons--nowadays /var/lock is used for a lot
more than just uucp, so expecting it to be owned by the uucp group
is, I think, unrealistic.  root:root or root:lock are the way things
have gone.

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

We don't currently permit changing of the ownership; the permissions
are entirely configurable in /etc/fstab.  You could use the tmpfs
uid= and gid=options to set the uucp group there.  We don't explicitly
cater for customisation here because the admin should never need
to change the ownership of these FHS-specified locations.

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

The liblockdev library exists to lock ttyS devices portably; any
program creating uucp-stype LCK..* files under /var/lock should be
using it.

Looking to the future, Linux permits the use of flock(2) on devices,
so the reality is that "lockfiles" are entirely redundant when you
can lock the device directly using an proper kernel-provided
advisory lock.  This is much more robust.  When I have time, I'll be
looking at making liblockdev use flock directly.

From what I've just been reading on RXTX file locks, it's rather
broken.
  (including http://rxtx.qbang.org/wiki/index.php/Trouble_shooting)
I think that, first and foremost, RXTX needs fixing.  It can use
liblockdev, which I see has already been suggested looking at list
archives with google.  It's basically using broken assumptions and
broken checks.  I don't think that breakage in a Java library can
really warrant changes to the default ownership of an FHS-standardised
directory.


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/0e61d7de/attachment.pgp>