Re: [PATCH v2] ceph: fix posix ACL hooks

[Linus Torvalds]

On Mon, Feb 3, 2014 at 1:19 PM, Al Viro <viro@xxxxxxxxxxxxxxxxxx> wrote:
>
> Please, don't do that.  Half of that is pointless (e.g. what you are
> doing with vfs_rmdir() - if anything, we could get rid of the first
> argument completely, it's always victim->d_parent->d_inode and we are
> holding enough locks for that to be stable) and ->permission() is
> just plain wrong.
>
> Result *is* a function of inode alone; the problem with 9P is that we
> are caching FIDs in the wrong place.

No, Al. It's *not* just a function of the inode alone. That's the point.

Some network filesystems pass the *path* to the server. Any operation
that needs to check something on the server needs the *dentry*, not
the inode.

This whole "the inode describes the file" mentality comes from old
broken UNIX semantics. It's fundamentally true for local Unix
filesystems, but that's it. It's not true in general.

Sure, many network filesystems then emulate the local Unix filesystem
behavior, so in practice, you get the unix semantics quite often. But
it really is wrong.

If the protocol is path-based (and it happens, and it's actually the
*correct* thing to do for a network filesystem, rather than the
idiotic "file handle" crap that tries to emulate the unix inode
semantics in the protocol), then the inode is simply not sufficient.

And no, d_find_alias() is not correct or sufficient either. It can
work in practice (and probably does perfectly fine 99.9% of the time),
but it can equally well give the *wrong* dentry: yes, the dentry it
returns would have been a valid dentry for somebody at some time, but
it might be a stale dentry *now*, and it might be the wrong dentry for
the current user (because the current user may not have permissions to
that particular path, even if the user has permissions through his
*own* path).

So I really think you're *fundamentally* incorrect when you say
"result *is* a function of inode alone".

                  Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/