4 ms·
the problem is, you can't really avoid this kind of race condition. Not in a pre-emptive system. You can't stat a file and open it at the same time: the whole p
by qwertyuiop924 10y ago
the problem is, you can't really avoid this kind of race condition. Not in a pre-emptive system. You can't stat a file and open it at the same time: the whole point of the stat is to see if you SHOULD open it. The best you could do is maybe stat the file after you open it. But I'm not sure what other problems that would cause.
- sebcat 10y agoyou call fstat on the opened file descriptor and compare device IDs and inodes, as was done in the referenced OpenBSD patch from -96: http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/libexec/mail.local/mail.local.c.diff?r1=1.1&r2=1.2&f=h http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/libexec/mail.lo... EDIT: corrected year
- ma2rten 10y agoI could think of multiple ways of fixing this problem changing the API. For instance they could have an api that opens the file only if it is not a synlink.
- tedunangst 10y agoLike open(O_NOFOLLOW)?
- nothrabannosir 10y agoThere are many possible solutions: Obtain a "session ID" through stat and always use that to access the file: id := stat("/a") read(id) write(id, ..) // doesn't protect race access to a file, // but at least you're not using the // pathname twice, which already solves a // lot of problems Use transactions: transid := ftransopen() f := stat("/a") read("/a") write("/a", ..) ftransend(transid) // fails if clashes with other fs changes Have "last modification ID" counters that change for every modification to a file, and allow CAS-style operations: mod := stat_mod("/a") open_mod("/a", mod) read_mod("/a", mod) mod2 := write_mod("/a", ..., mod) // fails if /a modified since mod mod3 := chown_mod("/a", ..., mod2) // fails if modified since mod2 etc. All with their own pros and cons, of course, but definitely possible. I'm just curious if there's a specific implementation that's gaining momentum.
- qwertyuiop924 10y agookay. neat. why did you use Go syntax?
- jandrese 10y agoWhat's so strange about stat() on the file after you open it? It's a security check against a known and abused exploit and it's not even hard to do. This seems like a simple fix to the problem. Just make sure you fstat() the file descriptor and not stat() the file to avoid a second race condition where a malicious actor undoes their attack immediately after you open() the file to hide the evidence.
- gpvos 10y agofstat is a more recent system call than stat, so old code bases do not use it, and mail.local is quite ancient. Although a quick lookup tells me that it appeared in 4.3BSD-Tahoe (June 1988) and SysVR4 (October 1988), so one would have expected all reasonable distributions to have gotten with the program by now.
- jandrese 10y agoA little digging suggests that mail.local appeared in Version 7 Unix from 1979, so it is not a surprise that it doesn't include a syscall invented 9 years later. Still, that syscall is 28 years old now. It's kind of embarrassing that nobody has gone though and checked for ancient and obvious privilege escalation issues like this. Or I guess they have, but on different OSes. This is one big downside to fragmentation, getting fixes distributed to all of the fragments.
- caf 10y agofstat() isn't the complete fix here - it doesn't protect you against opening/creating an unintended file through a symlink, for which you need O_NOFOLLOW (which is a bit more recent).
- qwertyuiop924 10y agoI had no idea if it was common or not, which is why I said I was unsure.