lkml.org 
[lkml]   [2007]   [Sep]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [NFS] [PATCH 2/7] NFS: if ATTR_KILL_S*ID bits are set, then skip mode change
    On Fri, Sep 14, 2007 at 09:38:46AM -0400, Jeff Layton wrote:
    > On Fri, 14 Sep 2007 23:09:24 +1000
    > Greg Banks <gnb@sgi.com> wrote:
    >
    > > On Fri, Sep 14, 2007 at 07:02:58AM -0400, Jeff Layton wrote:
    > > > On Fri, 14 Sep 2007 20:25:45 +1000
    > > > Greg Banks <gnb@sgi.com> wrote:
    > > >
    > > > > I'm curious about the reasons behind this change. You mention
    > > > > credential issues; how exactly is it that you have the correct creds
    > > > > to perform a WRITE rpc but not a SETATTR rpc?
    > > > >
    > > >
    > > > Consider this case. user1 and user2 are both members of group
    > > > "allusers":
    > > >
    > > > user1$ echo foo > foo
    > > > user1$ chgrp allusers foo
    > > > user1$ chmod 04770 foo
    > > > user2$ echo bar >> foo
    > > >
    > > > On most local filesystems, this would work correctly. The end result
    > > > would be a file with mode 0770 and the expected contents. On NFS
    > > > though, the write by user2 fails. When the write is attempted, the
    > > > kernel tries to squash the setuid bit using the credentials of user2,
    > > > who's not allowed to change the mode. The write then fails because the
    > > > setattr fails.
    > >
    > > Ok, I ran an experiment and I see this failure mode.
    > >
    > > So the SETATTR rpc is really a side effect of the client kernel's
    > > behaviour and not an operation directly requested by the user process
    > > on the client. Is there any reason why that rpc needs to have user2's
    > > creds? Why not do the rpc with a fake set of creds with uid and gid
    > > set to the uid and gid of the file, in this case user1/allusers ?
    > > That way the rpc will most likely pass the server's permission check.
    > >
    >
    > That might work in some cases, but there are many where it wouldn't...
    >
    > Suppose user1 here is root and all of the user1 operations are being
    > done on the server. If the server has root squashing enabled, then
    > user2's operation would still fail.

    In that case, user1's operations would also fail, which is even more
    serious a problem. Also arguably you actually *want* writes by a
    nonroot user to a setuid root executable to fail ;-)

    > Another problem:
    >
    > Suppose we're using gssapi. There's no guarantee that the client will
    > have the proper credentials to fake up a call as user1 (you might need
    > user1 krb5 tickets, etc).

    Yes, good point. You could use the root creds, except for root squashing.
    Ok, you convinced me.

    Greg.
    --
    Greg Banks, R&D Software Engineer, SGI Australian Software Group.
    Apparently, I'm Bedevere. Which MPHG character are you?
    I don't speak for SGI.
    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2007-09-14 16:43    [W:0.030 / U:0.176 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site