Re: [PATCH v3] vfs: new O_NODE open flag

[Alan Cox]

> > 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-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/