Hello!
On Thu, Apr 27, 2006 at 10:28:16AM +1000, Neil Brown wrote:
> > 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??
No. E.g. Lustre is usually bypassing local permission checks since server would
do those anyway. In this case we need to explicitly tell server that
client did the check and server should skip it.
> 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?
If non-root process would be able to read/write files they own with 0 permission
bits set, then various posix/whatever conformance testing suites regard this
as a bug.
> 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.
I also do not think this is all that big problem, as owner can do
chmod as well.
I just do not want to add any extra arguments to ->open() methods or something
equally ugly to hide this flag from userspace.
Bye,
Oleg
-
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
