We have been testing with some of the newly proposed security checks from the Yama security module. Some of the pending checks for that module use inode ownership and permissions as factors in these checks, checks essentially done at the VFS level. The issue I am seeing is that not all filesystems populate i_uid or i_mode (completely). Overlayfs for example does not populate i_uid in its inodes. This leads these Yama checks to fail unexpectedly. 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. I am hoping that someone in the know could clarify what you may rely on when at the VFS layer, or point me at the documenation if I have missed it. 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
