[lkml]   [2009]   [Dec]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH v3] vfs: new O_NODE open flag
> > 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

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

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.

[1] If you think about it a wait for no references is the same barrier as
a revoke but a blocking one.

 \ /
  Last update: 2009-12-07 15:13    [W:0.057 / U:1.404 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site