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

[Lennart Poettering]

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.

I think it is a good idea to ensure that no new software invents new
lock files or directories beneath /var/run. But for legacy software and
for software involving ttyS0 handling there are only two options: a) go
on with the insecure solution most distros have adopted or b) fix
things, and acknowledge that LCK.. will continue to exist for a while,
but at least create them somewhat securely.

> So if legacy compat isn't needed one could just use fcntl for
> locking the devices (maybe time to fix the kernel in case that
> doesn't work already). Programs using liblockdev would transparently
> use the new method, we'd have one less ugly setgid program, the stale
> lock file problem wouldn't exist anymore and locking would work for
> chroots too. 

Don't use fcntl() style locks please. They are evil.

http://0pointer.de/blog/projects/locking
http://0pointer.de/blog/projects/locking2

BSD locks FTW!

Recent fsck versions use bsd locks on device nodes to serialize fscking
on rotating media. That's how things should be done. However, in the
fsck case it is sufficient to lock fsck against fsck. and there was no
pre-existing locking scheme for that. That's different for serial
devices.

Lennart

-- 
Lennart Poettering - Red Hat, Inc.