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. -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
