On Saturday April 22, green@xxxxxxxxxxxxxx wrote: > Hello! > > NFSD does its own internal checks to possibly override restrictive file mode > for file owner already, to allow writing into (opened) file with some > restrictive mode (like 0000). But it does not pass this info down to > actual filesystems, and if that filesystem is also doing permission checks > in open, such an open would fail at FS-level. > (I thought of making an example with NFS exported with NFS, but this appears > to be not allowed, so I choose different example). > For example Lustre is contacting its metadata server for every open, and > metadata server does permission checks for open, obviously. > > I wonder if something like the patch below can be useful for any other > distributed FS now in use and ultimately to end up accepted into vanilla > tree? > Would it be acceptable for the lowlevel filesystem to simply always assume OWNER_OVERRIDE?? There are no security concerns in allowing read or write access to an owner. The IRUSR bit is almost entirely pointless, and the IWUSR bit is at most hint for user-level processes. Given that you know the syscall interface will be checking these, and given that they have no security implication, is there really any value in having the lowlevel filesystem check them as well? Other than that, my only concern is that it seems to allow a user-space application to open a file with O_OWNER_OVERRIDE and you would want that sort of change to get wide visibility. I don't think it is a problem, but there might be those who would. NeilBrown - 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
