> > First obvious attack: get an O_NODE handle to a device you have assigned > > to your ownership > > > > while(1) > > fchmod(fd, 0666); > > > > wait for device to unload, reload and be intended for another user > > Race udev to a real open. You have a similar problem with vhangup() and > > ttys. > > If this was a udev device, the same attack is possible with a hard > link to the device. Except the attacker simply does link() instad of > open(O_NODE) and chmod() instead of fchmod(). If your distribution does not use a separate tmpfs for devices then yes - but that's old news - and also needs revoke() to fix. It's a requirement of udev as it stands that it runs on its own file system and I would hope that all distributions using udev get this right. With O_NODE I don't need to make the hardlink and all the "same as a hardlink" justifications come crashing down. This always comes back to the same thing - you need revoke() on device files. The general case revoke is much more questionable (and indeed almost every Unixen with revoke does not support revoke of files) So we are back where we started - a prerequisite for O_NODE is revoke() at least for device files and possibly for O_NODE opens on normal files. O_NODE isn't per-se the problem, the problem is the lack of revoke() - it just gets caught up in the fallout along with many other things including all sorts of stuff the GUI folks want to do but cannot currently provide. Alan -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
