> > That is *exactly* the problem, which is clearly what you are missing here. > > I don't think so, but maybe I'm wrong. Could you describe your attack > scenario in detail then, please? 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. This cannot happen with the existing kernel because there cannot be an open handle when the original device unload occurs[1] and it cannot happen with vhangup because the hangup is basically a special case revoke() implementation for tty devices. O_NODE changes the whole lifetime semantics for inodes. It's not something you can do casually. pioctl() gets this right although for the same reason as path based chmod/chown/etc all get it right, O_NODE breaks it all horribly. Alan [1] If you think about it a wait for no references is the same barrier as a revoke but a blocking one. -- 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
