Re: Can the VFS layer rely on i_uid

[Al Viro <viro@ZenIV.linux.org.uk>]

On Mon, Mar 05, 2012 at 12:12:39PM +0000, Andy Whitcroft wrote:

> When an inode does not provide a permissions() op generic permissions
> checks are used and these assume that i_mode, i_uid, and i_gid are
> all populated, using them directly to perform these checks.  When a
> permissions() op is provided obviously this code is not used.  What is not
> so clear to me is whether there is still an assumption or requirement that
> these are populated in this case.  My gut feeling is that if you have a
> permissions() op then there is no obligation to use these fields at all,
> indeed it seems entirely reasonable that your permission model not map
> sensibly onto such permissions.

Not quite...  Ideally, yes, we'd want to have ->i_uid used only by fs-specific
code and helpers used by that fs (including those that are implicit defaults).
And BTW, you proposal to have non-trivial differences in behaviour of code
based on whether ->permission() (and ->getattr()) is NULL is an atrocity -
this kind of layering violations is wrong and brittle, so please abstain from
that.  In practice we have enough places where uid/gid is used directly
to make setting them practically a requirement - places like /proc/<pid>/
can get away with not doing that, but only because shitloads of syscalls
are not allowed on those anyway, permissions or no permissions.  In anything
general-purpose you really need to set it.