Bug 14295

Summary: NFS insecure without support for squashing multiple groups
Product: File System Reporter: Paul Szabo (psz)
Component: NFSAssignee: bfields
Status: RESOLVED WILL_NOT_FIX    
Severity: enhancement CC: jrnieder, psz
Priority: P1    
Hardware: All   
OS: Linux   
Kernel Version: Subsystem:
Regression: No Bisected commit-id:

Description Paul Szabo 2009-10-01 22:01:03 UTC
Please support squashing multiple groups for NFS.
For discussion please see
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=384922

Thanks,

Paul Szabo   psz@maths.usyd.edu.au   http://www.maths.usyd.edu.au/u/psz/
School of Mathematics and Statistics   University of Sydney    Australia
Comment 1 Trond Myklebust 2009-10-02 12:51:19 UTC
That's a tad misleading. The title should be "Debian NFS insecure without...".
Most of the rest of us don't have this problem...

This looks more like a feature request than a bug report to me. The right
address for that kind of discussion would be on the linux-nfs@vger.kernel.org
mailing list, not bugzilla.

Anyhow. Rerouting this to Bruce in case he has comments.
Comment 2 bfields 2009-10-02 16:04:13 UTC
Right, a good first step would probably be a post to linux-nfs@vger.kernel.org summarizing the requirements (and maybe proposing a user-interface for) the mechanism that you're asking for.

There have been a few requests over the years for various kinds of server-side auth_sys credential mapping.  A brief marc.info search isn't finding them.

There's nobody that I know of working on this sort of problem currently.
Comment 3 Jonathan Nieder 2011-08-05 16:03:45 UTC
Hi Paul,

(In reply to comment #0)

> Please support squashing multiple groups for NFS.
> For discussion please see
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=384922

Did you raise this request to support restricting privileges of remote root-equivalent users and groups on the linux-nfs@vger list?  Any conclusions or other news?
Comment 4 Anonymous Emailer 2011-08-05 21:13:20 UTC
Reply-To: paul.szabo@sydney.edu.au

> Did you raise this request ... on the linux-nfs@vger list?

Sorry, no. The reason I reported to bugzilla.kernel.org was because
Moritz Muehlenhoff <jmm@inutil.org>
told me to do so in
http://bugs.debian.org/384922#147
Then I asked how to follow up on linux-nfs@vger.kernel.org in
http://bugs.debian.org/384922#159
but did not receive a reply.

Cheers, Paul

Paul Szabo   psz@maths.usyd.edu.au   http://www.maths.usyd.edu.au/u/psz/
School of Mathematics and Statistics   University of Sydney    Australia
Comment 5 Jonathan Nieder 2011-08-05 21:16:00 UTC
bugzilla-daemon@bugzilla.kernel.org wrote:

> I asked how to follow up on linux-nfs@vger.kernel.org in
> http://bugs.debian.org/384922#159
> but did not receive a reply.

Okay, better late than never.  The answer to

> Is there anything I should do? I would not know what user interface to
> propose.

is that the kind people on the linux-nfs should be able to help with
coming up with a good user interface.  The point of writing to that
mailing list is to get hints about the design and ideally to find
some likeminded people to carry it out.

Thanks for your work, and hope that helps.
Comment 6 Anonymous Emailer 2011-08-19 02:15:17 UTC
Reply-To: paul.szabo@sydney.edu.au

Now followed up on linux-nfs@vger.kernel.org mailing list,
please see:
http://www.spinics.net/lists/linux-nfs/msg23450.html

Cheers, Paul

Paul Szabo   psz@maths.usyd.edu.au   http://www.maths.usyd.edu.au/u/psz/
School of Mathematics and Statistics   University of Sydney    Australia
Comment 7 Paul Szabo 2012-01-13 01:17:44 UTC
[ Tried to send this to bugzilla-daemon@bugzilla.kernel.org
  on 5 Oct 2011 but that bounced. ]

The consensus on the linux-nfs@vger.kernel.org mailing list:
http://www.spinics.net/lists/linux-nfs/msg23450.html
http://www.spinics.net/lists/linux-nfs/msg24148.html
http://www.spinics.net/lists/linux-nfs/msg24468.html
is to use NFSv4 with kerberos authentication. Since kerberos only has
a concept of "principals" (i.e. UIDs) but not of groups, we cannot be
affected by privileged GIDs sent by the client; and user mapping is
provided with idmapd.

However, NFSv4 is regarded as "experimental" in my (Debian squeeze)
version of the kernel; and kerberos is not simple to set up or to use.
Maybe, I will try to add code to mountd and to the kernel to do things
"right", even with NFSv3.

Cheers, Paul

Paul Szabo   psz@maths.usyd.edu.au   http://www.maths.usyd.edu.au/u/psz/
School of Mathematics and Statistics   University of Sydney    Australia
Comment 8 bfields 2012-01-14 00:13:56 UTC
"NFSv4 is regarded as "experimental" in my (Debian squeeze) version of the kernel"

Note that krb5 also work with NFSv3, and I'd expect the kernel included in squeeze to have reasonable rpcsec_gss/krb5 support.

"kerberos is not simple to set up or to use."

That's something we should fix.
Comment 9 Paul Szabo 2012-01-14 08:09:53 UTC
>> The consensus on the linux-nfs@vger.kernel.org mailing list ...
>> is to use NFSv4 with kerberos authentication. ...
>> However, NFSv4 is regarded as "experimental" in my (Debian squeeze)
>> version of the kernel...
> 
> Note that krb5 also work with NFSv3 ...

But I was told that would not fix this problem, e.g.:
http://www.spinics.net/lists/linux-nfs/msg23488.html
  when the client issues a chown/chgrp request, the uid/gid is used
  directly - idmap does not have a chance to filter/translate it
  (in v4 it does).
  When the client issues a getattr, the uid/gid are passed through
  unchanged.  idmap does not get to translate it (in v4 it does).

> ... and I'd expect the kernel included in
> squeeze to have reasonable rpcsec_gss/krb5 support.

Yes that seems fine, I did not need any kernel changes to enable NFSv4
with krb authentication, other than to turn on
  CONFIG_NFS_V4
  CONFIG_NFSD_V4
  CONFIG_RPCSEC_GSS_KRB5
in the kernel configs.

>> ... kerberos is not simple to set up or to use.
>
> That's something we should fix.

Cheers, Paul

Paul Szabo   psz@maths.usyd.edu.au   http://www.maths.usyd.edu.au/u/psz/
School of Mathematics and Statistics   University of Sydney    Australia
Comment 10 bfields 2012-10-30 16:17:09 UTC
Doesn't seem like anyone has plans to work on the original request; closing for now.