On Fri, 01.04.11 11:37, Ludwig Nussel ([email protected]) 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. _______________________________________________ systemd-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/systemd-devel
