---------- Forwarded message --------- From: Mike Marshall <hubcap@xxxxxxxxxxxx> Date: Tue, Nov 26, 2019 at 4:02 PM Subject: Re: [PATCH V3] orangefs: posix open permission checking... To: Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> Cc: <hubcap@xxxxxxxxxx>, linux-fsdevel <linux-fsdevel@xxxxxxxxxxxxxxx> >> I don't know what side effects that "new_op->upcall.uid = 0;" will >> have on the server side I believe that the 0 is only used for whatever filesystem operations (usually one) are required to get this service_operation done. I think it will only kick in during discrete IO operations that we've already posixly promised to complete. I still am looking for a kernel access()-like thing so I can only use UID 0 when needed - I see your argument about always doing it... The orangefs people are interested in this, so they'll be looking at this last iteration. Thanks for helping me to understand the right way to look at it from the kernel's perspective. -Mike On Tue, Nov 26, 2019 at 2:23 PM Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> wrote: > > On Tue, Nov 26, 2019 at 10:50 AM <hubcap@xxxxxxxxxx> wrote: > > > > Here's another version that is hopefully closer to > > usable... > > This looks like it should work. > > I don't know what side effects that "new_op->upcall.uid = 0;" will > have on the server side, and it still looks a bit hacky to me, but at > least it doesn't have the obvious problems on the client side. > > Arguably, if you trust the client, you might as well just *always* do > that upcall.uid clearing. > > And if you don't trust the client, then you'd have to do some NFS-like > root squash anyway, at which point the uid clearing will actually > remove permissions and break this situation again. > > So I do think this shows a deeper issue still, but at least it is an > understandable workaround for a non-posix filesystem. > > Linus
