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

Lennart Poettering lennart at poettering.net
Thu Mar 31 15:33:01 PDT 2011


A few minutes ago there was a discussion on #systemd involving lots of
folks (from various distros even), regarding the chaotic setup of
/var/lock on most distros. As it turns out every distro set this up
differently, and almost all of them insecurely in one way or another.

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.


- We need to separate system service locks (i.e. root-only locks as
  stored in /var/lock/lvm/* or /var/lock/subsys/*) from LCK..xxx device
  locks (locks which user programs may acquire). Otherwise it is
  possible for users which somehow manage to get into the lock group to
  replace files like /var/lock/lvm or
  /var/lock/subsys by their own files, for example symlinks, which can
  be used to to exploit the system if later on an unexpecting root
  process accesses the dir again. This is explained in more detail here:


- We cannot use the sticky bit on the LCK..xxx dir, because user apps
  must be able to remove stale lock files of other users:


- We should not create another world-writable dir, hence limit access to
  a group "lock", so that only apps which are in that group can create
  an LCK..xxx lock. it is recommended to do that with a library such as
  liblockdev, which comes with a little setgid helper which creates the
  actual file.

I have also filed a bug against the (dead, but hey, let's think positive)
FHS in the hope this gets standardized one day:


I have also changed the default tmpfiles file in systemd
accordingly. Distros may deviate from this by patching this downstream,
but by shipping this as secure default I do hope to gently push
everybody in the same direction.

What does that mean for you, distro packager?

1. File a bug against your distro copying
   https://bugzilla.redhat.com/show_bug.cgi?id=581884 if it is
   vulnerable, since this is a security hole that should be fixed.

2. Two options:

   A: Patch our new defaults out, and ignore our suggestions and do your
   own stuff.

   B: Adapt the suggested scheme in your distro: introduce a "lock"
   group, and change all apps writing LCK..xxx lock files to
   do so in /var/lock/lockdev/ and that after becoming a member of
   "lock" somehow, in case the process is not privileged.

Ideas? Comments? Suggestions?

Thanks everybody who explained the intricacies of all of this to me,
Michal, Karel, Michael in particular.


Lennart Poettering - Red Hat, Inc.

More information about the systemd-devel mailing list