On Mon, Mar 5, 2012 at 1:26 PM, Al Viro <viro@xxxxxxxxxxxxxxxxxx> wrote: > 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. I was not trying to suggest that code could look at whether ->permission() was NULL from above and use that to rely on the values *shudder*. I was mearly expressing the feeling that it seemed that there was a distinct possibily that those fields were really only there for the ops and below to use. From your description here it seems we should be able to assume these fields are populated, which makes these Yama checks valid and so I need to look to have them populated. Thanks. -apw -- 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
