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

[Lennart Poettering]

On Fri, 01.04.11 18:13, Kay Sievers (kay.sievers at vrfy.org) wrote:

> 
> On Fri, Apr 1, 2011 at 16:37, Ludwig Nussel <ludwig.nussel at suse.de> wrote:
> > The other option would be to leave that legacy crap alone and only
> > deprecate use of subdirectories in /var/lock.
> 
> That wold probably the best option. lockdev could just go straight
> into /run/lockdev/ then, and leave the silly shared directory with
> magic filenames alone.

I see no value in making these legacy locks even more prominent by
giving them their own directory on level up.

> It's kind of weird, to invent any new subdir there, keeping in mind
> how broken the entire concept is. I really doubt, that any other
> software will or should be changed to look directly for files in this
> new directory.

Well, it's not invented now, it's how Fedora has been doing things for a
while. 

You have three options basically:

1) Leave things as they are with major security holes

2) Go all the way, and remove support for LCK.. lock files from all
   programs, port them to flock() instead.

3) Separate the LCK..xxx lock files from the rest, fixing the security
   hole, and simply pass a different compile time switch to various
   programs.

I don't think we should do #1. #2 is the right thing to do, but it's
nothing I believe we can pull off just like that. The patches are more
than one-liners, and it's a lot of software that needs to be patched.

Leaves #3.

As mentioned I have now placed the rules for /var/lock/lockdev into a
separate tmpfile legacy.conf which hopefully emphasizes that this crap
should go in the long run (and I added comments explaining that to
it). Also, this file is no longer installed if you disable legacy
support in systemd during build time.

I fear LCK.. is much like SysV init scripts something that will take
time to get rid of, and that we will have to support for a while in
systemd. But we can mark it as "legacy" and add support for builds
without it.

Lennart

-- 
Lennart Poettering - Red Hat, Inc.