Bug 35895

(Also happy to split out the two portions of the patch, since I suspect /run might prove more controversial than /run/lock; the latter represents a regression, the former not.)

No, we definitely don't want to add two more /tmp like security holes. Also, the sticky bit doesn't work, since you need to allow users to remove stale lock files of other users. You don't want to allow arbitrary users fill up the tmpfs. You don't want to allow normal users to trigger DoS problems by creating a directory beneath /var/run then later on wants to be used by system daemon.

This all is discussed here:

http://lists.freedesktop.org/archives/systemd-devel/2011-March/001823.html
https://bugzilla.redhat.com/show_bug.cgi?id=581884
https://bugzilla.redhat.com/show_bug.cgi?id=145264#c1
http://bugs.freestandards.org/show_bug.cgi?id=719

(In reply to comment #2)
> No, we definitely don't want to add two more /tmp like security holes. Also,
> the sticky bit doesn't work, since you need to allow users to remove stale lock
> files of other users. You don't want to allow arbitrary users fill up the
> tmpfs. You don't want to allow normal users to trigger DoS problems by creating
> a directory beneath /var/run then later on wants to be used by system daemon.
> 
> This all is discussed here:
> 
> http://lists.freedesktop.org/archives/systemd-devel/2011-March/001823.html
> https://bugzilla.redhat.com/show_bug.cgi?id=581884
> https://bugzilla.redhat.com/show_bug.cgi?id=145264#c1
> http://bugs.freestandards.org/show_bug.cgi?id=719

Sigh.  Ignoring /var/run for the moment (since I learned of XDG_RUNTIME_DIR and thus don't feel like arguing that point), making /var/lock not user-writable will cause a regression for existing programs which expect to create lock files there.  "stale lock files" don't seem like a justification for allowing user programs to remove locks legitimately created by other users (or root).  Conversely, allowing arbitrary users to remove files created by other users seems like the more critical security problem.  As for filling up the tmpfs, that can occur anyway via XDG_RUNTIME_DIR, with the same solution: use a quota if you care.  (They can also fill up RAM easily enough if you let them, with a similar solution.)

Reopening with narrowed scope.

(In reply to comment #3)
> (In reply to comment #2)
> > No, we definitely don't want to add two more /tmp like security holes. Also,
> > the sticky bit doesn't work, since you need to allow users to remove stale lock
> > files of other users. You don't want to allow arbitrary users fill up the
> > tmpfs. You don't want to allow normal users to trigger DoS problems by creating
> > a directory beneath /var/run then later on wants to be used by system daemon.
> > 
> > This all is discussed here:
> > 
> > http://lists.freedesktop.org/archives/systemd-devel/2011-March/001823.html
> > https://bugzilla.redhat.com/show_bug.cgi?id=581884
> > https://bugzilla.redhat.com/show_bug.cgi?id=145264#c1
> > http://bugs.freestandards.org/show_bug.cgi?id=719
> 
> Sigh.  Ignoring /var/run for the moment (since I learned of XDG_RUNTIME_DIR and
> thus don't feel like arguing that point), making /var/lock not user-writable
> will cause a regression for existing programs which expect to create lock files
> there.

Well, in multiple distributions access to /var/lock was already limited to programs setgid lock. If apps use libraries like liblockdev which include a setgid helper (and they shoiuld), there is no real problem here.

>   "stale lock files" don't seem like a justification for allowing user
> programs to remove locks legitimately created by other users (or root). 

No doubt that LCK.. style lock files are broken. But they are cooperative by nature, and do not clean themselves up if an application dies. Due to that it must be possible to delete other people's lock files.

The right way to lock devices is probably using BSD locks. See 

http://lists.freedesktop.org/archives/systemd-devel/2011-April/001834.html

and the surrounding thread.

> Conversely, allowing arbitrary users to remove files created by other users
> seems like the more critical security problem.  As for filling up the tmpfs,
> that can occur anyway via XDG_RUNTIME_DIR, with the same solution: use a quota
> if you care.  (They can also fill up RAM easily enough if you let them, with a
> similar solution.)

There is no quota on tmpfs right now. Also, what you want here is a bit of an inverse quota which cannot even be expressed with the ext3 quota system: uids < 500 must always have space for a certain amount of storage.