[systemd-devel] [HEADSUP] /var/lock and /var/lock/lockdev

[Ludwig Nussel]

Lennart Poettering wrote:
> On Fri, 01.04.11 11:37, Ludwig Nussel (ludwig.nussel at suse.de) wrote:
> > Lennart Poettering wrote:
> > > I'd like to see this cleaned up and standardized in a secure way among
> > > the distros, so here's what I propose for adoption:
> > > 
> > >     /var/lock should be root:root 0755 and the place for various system
> > >     service lock directories such as /var/lock/subsys or /var/lock/lvm.
> > > 
> > >     /var/lock/lockdev should be root:lock 0775 and the place for
> > >     LCK..xxx style device lock files.
> > 
> > Those strangely named lock files in /var/lock only exist because of
> > legacy programs. If they are no longer put in /var/lock you're
> > throwing away the legacy compatibility and you don't actually need
> > to create those files at all anymore.
> 
> Well, there's not doubt that LCK..xxx locks are evil. However, many many
> tools use them, hence we need support them. In most packages the path
> for these locks can be configured at build time, a task easily
> accomplished by distros as shown by the Fedora example. However,
> patching this kind of locking out and replacing it by BSD locks or
> something like that is a massive amount of work.

Chickening out already? Come on :-)
Speaking only of openSUSE no unprivileged program could ever write
to /var/lock without setgid which in turn is centrally tracked. So
programs are either linked to liblockdev (11.3+), are called uucp
itself or are broken and noone noticed or cared anyways.
Fixing the central place liblockdev should be easy.

In any case declaring some directory as the standard place for lock
files doesn't fully solve the problem anyways. The exact lock file
naming isn't quite standardized either. There's at least the FHS
"LCK..name" method and the SVr4 "LK.dev.maj.min" method. Both have
their problem. Ie what if the device name contains slashes? What if
you want to lock a block and a character device with the same
major/minor?
So I'd rather recommend the ttylock.h interface as standard and hide
the implementation details of whether a setgid helper, flock or
whatever is used. Heck, you could even route the ttylock calls
through systemd to have it create the legacy files in /var/lock as
root without the need group writeable stuff (good old resmgr did
that).

The other option would be to leave that legacy crap alone and only
deprecate use of subdirectories in /var/lock. FHS doesn't say
anything about subdirectories there anyways.

cu
Ludwig

-- 
 (o_   Ludwig Nussel
 //\
 V_/_  http://www.suse.de/
SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nuernberg)