All of lore.kernel.org
 help / color / mirror / Atom feed
From: Frank van Maarseveen <frankvm@frankvm.com>
To: Neil Brown <neilb@suse.de>
Cc: Linux NFS mailing list <nfs@lists.sourceforge.net>
Subject: Re: 2.6.21 strange optimization in svcauth_unix.c
Date: Sat, 28 Apr 2007 12:47:37 +0200	[thread overview]
Message-ID: <20070428104737.GA3827@janus> (raw)
In-Reply-To: <17971.4989.320259.441338@notabene.brown>

On Sat, Apr 28, 2007 at 07:27:25PM +1000, Neil Brown wrote:
> On Friday April 27, frankvm@frankvm.com wrote:
> > While reading the 2.6.21 version of net/sunrpc/svcauth_unix.c it looks
> > to me that it tries to cache the AUTH_UNIX/AUTH_SYS group list on uid
> > basis and thus deliberately ignore the group ids supplied by the NFS
> > client.
> 
> It is configurable by a switch to mountd, and defaults to 'off'.
> 
> When a request arrives, the kernel tries to ask mountd to map the uid
> to a list of gids.  If mountd says "no", the kernel uses whatever was
> in the RPC request.  If mountd says "yes", the kernel uses the group
> list that mountd provided.  mountd can provide a full list of gids,
> not just the first 16.
> 
> So it is really an alternate to hacking the NFS client.  If you have a
> new kernel and new nfs-utils and run mountd with "-g", you don't need
> your changes to the NFS client.

Thanks for the explanation. It probably wouldn't work in my case
because the secondary group list is set by a setuid root wrapper
around /bin/sh depending on the project one wants to work on. This
allows delegating access control to people without having to
hand out root passwords (it's more complicated but basically this
describes it).

When mountd can do a callout to a program supplying both uid and gid
to obtain the secondary group list then it could be a replacement
for the client side patch for me. It will never be a replacement
for non-linux NFS servers though. Maybe I'll replace the client
side patch by a (smaller) server side patch if that one is easier
to maintain.

I have given up all hope long time ago to get my client side
patch merged.

-- 
Frank

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

      reply	other threads:[~2007-04-28 10:47 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-04-27 17:19 2.6.21 strange optimization in svcauth_unix.c Frank van Maarseveen
2007-04-28  9:27 ` Neil Brown
2007-04-28 10:47   ` Frank van Maarseveen [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20070428104737.GA3827@janus \
    --to=frankvm@frankvm.com \
    --cc=neilb@suse.de \
    --cc=nfs@lists.sourceforge.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.