[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
> >        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.
> Huh? I would've thought that udev would (and already does?), on
> device unload, chown to 0:0, then chmod to 0000, then unlink, in which
> case that attack doesn't work.

udev doesn't control the device unload/reload. It responds to messages
from the kernel which are to some extent asynchronous to actual events.
It may be ok if udev is very careful but the fact it requires a close
inspection of the kernel and user space sides doesn't bode well (with or
without O_NODE). The fact we currently have an implied revoke by the
device refcounts is a big helper at the moment.

The tty cases using vhangup() assume that the handle is killed and would
also need addressing.

> Would you be okay with a patch that prevented opening
> /proc/self/fd/xxx on O_NODE handles? I personally don't care about

I'd like to see what Al Viro has to say on the subject first.
The /proc/self stuff bothers me less - I've not seen a convincing
description of it being misuable where ptrace wouldn't allow the same
actions. Even the constructed scenarios share that property.

> O_NODE all that much, but I'd like a decent in-kernel AFS
> implementation (and a decent revoke() implementation, and especially
> the ability to revoke whole filesystems would be really nice too).

The AFS case is probably the easier one - its things like device files
where one handle can change completely what it references (due to device
loads/unloads and dynamic major/minor assignment) that make it evil.

CIFS/SMB is horrible for different reasons (a handle open on some piece
of namespace isn't going to always been the same actual file) but you
could simply decide CIFS/SMB and any other problematic cases don't
support it.

I don't really have a problem with it providing its restricted to
ordinary files on a file system where having a local inode reference
means you have a stable reference to an object on the remote system or
the local media.

The way to start this is firstly to convince Al Viro (always a good
sanity check), and then to start with the obviously safe cases only -
regular files, only file systems with stable inode references.

Devices are hard - why do we need O_NODE on devices anyway ?

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

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