Hacker News Reader

Comment by ZeroConcerns | Hacker News Reader

Somehow I feel that if all the time that has been invested in debating and discussing this had been spent on patching the affected apps, the problem would be properly solved.

I mean, yeah, I get it, systemd bad, democracy good, but these world-writable lock folders are actually a huge pain, and adding some shim code to upgrade to a more secure solution seems achievable?

View on HN

Genuinely curious - why would world-writeable directory be bad for security? Assuming of course, it's on a separate filesystem mounted with sensible options. Here's what I see from "grep /run/lock /proc/mounts" in sid:

  rw,nosuid,nodev,noexec,size=5120k

The classic is say you know a root process will write a file called foo.lock in /run/lock, and you (a bad person) have write access to that directory. Then you make foo.lock a symlink to some file (/bin/init or /bin/sh or ld.so for example would be very inconvenient choices) and when the root process writes its lock it destroys that file.

Now obviously people these days generally know about that so hopefully don’t use predictable file names but that’s one way.

> and when the root process writes its lock it destroys that file.

Unless you do open("/run/lock/foo.lock", O_WRONLY|O_CREAT|O_EXCL|O_NOFOLLOW)

Yep. And for good measure, first open with O_CREAT as tempfile with random name, then rename() it to predictable "foo.lock".

Yup to both of you. But all of this is to say, running shellscripts as root (in particular) needs to be done with extreme care, because if people forget those precautions when writing C, they sure as heck don’t trouble themselves to do it when they’re writing shell.

I remember the time (around 2001-2002) when just about every binary was discovered to have some variant on this exact exploit. I happened to be linux sysadmin for a very large, high-profile set of linux boxes at the time. Happy times.

> Now obviously people these days generally know about that so hopefully don’t use predictable file names but that’s one way.

Annoying side effect: now you gotta guess which process created the darn lockfile.

A more sensible approach is to do sanity checking on the lockfile and its contents (i.e. does the contained PID match one's own binary).

> now you gotta guess which process created the darn lockfile

Or you can use “lsof” to just tell you.

The argument is also that you could effectively DoS the system by exhausting space or inodes.

Hmm - I see there's now "lockdev" for managing access to things like serial lines, but what's the preferred method of expressing "only one instance of this program should run at any one time"?

I don't know what the preferred method is. But so far, flocking on my own executable works for me.

Reply on news.ycombinator.com