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

[Lennart Poettering]

On Fri, 01.04.11 16:37, Ludwig Nussel (ludwig.nussel at suse.de) wrote:

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

I am not sure it is actually.

I believe the most elegant and simple way to lock a tty device is by
just calling flock() on the tty fd. The lockdev API is not suitable for
such an API, since it takes no fd, only a device name. (And it must be
the fd the app actually uses that is locked, because the lock goes away
automatically on close()).

If we do things cleanly, then liblockdev should go, people can just call
flock() directly, no need for an extra dep.

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

I have never seen LK.x.y.z files. Documentation link?

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

ttylock.h seems to be a header that maps things directly onto lockdev.h
calls. It also suffers by the problem that flock() cannot be mapped to
it, since it takes no fd.

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

Too many packages use those dirs. I do agree though it's a bad idea to
use them, and people should keep their internal locks in /run (or
/var/run) instead, placing them in /var/lock/ is a bad idea.

So here's what I changed now in git:

I moved the creation of /var/lock/subsys and /var/lock/lockdev into a
seperate "legacy.conf" tmpfiles file, which is only installed when you
enable the legacy/SysV support in systemd at compile time.

On a legacy-free system, especially embedded ones these two directories
won't exist at all hence.

Eventually we will drop these legacy features from systemd. I just doubt
that we can pull it off to remove /var/lock right now, even if we really
should. Simply because too many things use it and there's no strong
incentive for people to fix it, and I don't want to patch them all
myself.

It's one thing extending the base that the FHS describes in a distro,
it's another thing dropping things that it defines, such as the
/var/lock directory.

Now, the only improvement on the brokeness of LCK..xxx style locks we
can pull off easily is seperating them from the other stuff that is
stored in /var/lock. And this is usually simple (compile time switches
in various programs), and actually implemented in Fedora.
 
I hope this makes some sense.

Lennart

-- 
Lennart Poettering - Red Hat, Inc.