Messages in this thread |  | | Subject | Re: [RFC] O_NOACC: open without any access | From | Miklos Szeredi <> | Date | Tue, 23 Jun 2009 22:04:10 +0200 |
| |
On Tue, 23 Jun 2009, Linus Torvalds wrote: > On Tue, 23 Jun 2009, David Howells wrote: > > > Miklos Szeredi <miklos@szeredi.hu> wrote: > > > > > Define O_NOACC as 3. On open(..., O_FILESYSTEM | O_NOACC) require no > > > privileges on the file. > > > > It must also work with O_NOFOLLOW, which I think your suggestion will. > > This does sound like a fairly natural extension of what we already do. > > We essentially already have O_NOACCESS (3), and use it exactly because we > need to do operations on a file descriptor without "real" accesses > (notably things like accessing /dev/cdrom without waiting/checking for the > disk being present etc). > > O_FILESYSTEM I don't like as a name (to me, it doesn't say _what_ it is > doing - of course an open works on a filesystem!), but the concept of > saying "don't follow device nodes - just open the node itself" makes > perfect sense. Together with O_NOFOLLOW it also fairly naturally means > "give me the actual symlink _node_, don't return error or follow it".
O_NODEV? It applies just as well to fifos, sockets and symlinks, but it's hard to express that in a compact way.
> That said, I do _not_ like the notion of > > > Add a new inode->i_filesystem_fop pointer > > regardless of whether it's in inode->i_op or wherever. I think we should > just handle this in the regular "inode->f_op->open" routine, the same way
No, it's a totally different open, one comes from the device/fifo code, the other from the filesystem. Yes, the filesystem could in theory wedge itself between the VFS and device's f_ops. Not sure if that's how this should be done, though...
Also how should the default case (filesystem doesn't handle O_NODEV) be handled. The nice thing about O_NODEV | O_NOACCESS would be that it could be implemented totally in generic code in a secure way and it would even be useful for a variety of cases.
Thanks, Miklos
|  |