Messages in this thread |  | | Subject | Re: [RFC] O_NOACC: open without any access | From | Miklos Szeredi <> | Date | Wed, 24 Jun 2009 13:12:19 +0200 |
| |
On Wed, 24 Jun 2009, Al Viro wrote: > i_filesystem_fop is certainly bogus, but why do we want to bother with > file_operations at all? > > Unless you really insist on unlimited use of ioctl(2) on such beasts (and > any users will be non-portable for obvious reasons anyway), there's no need > to go anywhere near ->open() *or* ->f_op in general. > > Just add new methods to ->i_op (and we already have that coming from > fs code) and teach do_filp_open() to > * call permission() with new flag (MAY_TALK_TO_FS_NODE) for such > open() > * do not die with -ELOOP on symlinks if we have O_NOFOLLOW + your flag > * do not call ->f_op->open() at all for such open() > and we are all set.
Sounds good.
> Hell, we can even teach sys_ioctl() that given set > of ioctls maps to calls of our new methods. Taken from ->i_op... > > If we want full-blown ->ioctl() coming from the fs code on such opens, we > will need distinct file_operations, no matter what we do with ->open(). > It's also doable (we'd need ->i_fop pointing to new foofs_special_file_ops > and its ->open() to be a boilerplate that would replace file->f_op with > the normal one in case of normal open()), but it's more boilerplate patches > and I really don't see what would it buy...
Adding boilerplate to _every_ filesystem sounds really fragile and stupid. At least add a filesystem (or inode) flag: FS_HANDLES_NODE_OPENS and otherwise don't call into filesystem's ->open().
Thanks, Miklos
|  |