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

[Joerg Dorchain]

On Mon, Aug 15, 2011 at 02:59:04PM +0100, Roger Leigh wrote:
> > > 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).

I am under the impression that these applications check for group
permissions, and consider a world-writeable directory unsafe. I have
only looked at strace output, not disassembled code.
> 
> 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.

I use this application roughly every  other week, on a machine
following testing, so I am quite sure the change happend in the
last few weeks.

As said, root:lock ownership with group-write permissions is
probably ok.
> 
> 
> 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.

Thanks for that hint.

> We don't explicitly
> cater for customisation here because the admin should never need
> to change the ownership of these FHS-specified locations.

Well, if all developers would follow the FHS, it would be great.
> 
> > 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.

I do not see a realistic chance to have this application changed.
> 
> 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.

I completely agree. However, this is an application from the
past, and not open source. Nevertheless I have not much choice but
using it.

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

Even if librxtx is ever fixed, that fixed version needs to make
it into the closed source apps of a commercial vendor. It will
take years.

> I don't think that breakage in a Java library can
> really warrant changes to the default ownership of an FHS-standardised
> directory.

As said, root:lock would also be ok. Even if you are not moving
away from FHS for policy reasons, just do not make it
unnecessarly hard to run with slight derivations from it.
Besides, I am sure it is not the only pre-FHS application out
there.

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/20110816/146f5880/attachment.pgp>