[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <E1MJQOp-0001Tx-4c@pomaz-ex.szeredi.hu>
Date: Wed, 24 Jun 2009 13:12:19 +0200
From: Miklos Szeredi <miklos@...redi.hu>
To: viro@...IV.linux.org.uk
CC: torvalds@...ux-foundation.org, dhowells@...hat.com,
miklos@...redi.hu, alan@...rguk.ukuu.org.uk, hch@...radead.org,
linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org,
adilger@....com, akpm@...ux-foundation.org
Subject: Re: [RFC] O_NOACC: open without any access
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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists