Subject: [nfsv4] Sharing with AUTH_NULL

From: Thomas Haynes <[email-masked]>
Date: Tue, 28 Jun 2011 17:38:44 -0500

Chuck just posted a set of changes in the way Linux clients mount under NFSv3:

> There is an undocumented convention (verified by reviewing network
> traces from a NetApp filer and a Solaris NFS server) where a server
> that returns a mount authflavor list containing an AUTH_NULL entry
> is actually indicating it will accept any security flavor for the
> export being mounted.
> 
> This might be used when the server maps all security flavors into the
> same security mode.  For example, the server treats all accessors as,
> say, UID 17.
> 
> Essentially, AUTH_NULL is treated as a wildcard that matches the
> flavor the mounter requested.

This convention is documented in both the Solaris and NetApp man
pages. Under Solaris, nfssec(5) has this to say:

     none                      Use      null       authentication 
                               (AUTH_NONE).   NFS  clients  using 
                               AUTH_NONE have no identity and are 
                               mapped   to   the  anonymous  user 
                               nobody by NFS  servers.  A  client 
                               using  a  security mode other than 
                               the one with which a  Solaris  NFS 
                               server  shares the file system has 
                               its  security   mode   mapped   to 
                               AUTH_NONE.  In  this  case, if the 
                               file   system   is   shared   with 
                               sec=none,  users  from  the client 
                               are mapped to the anonymous  user. 
                               The NFS security mode none is sup- 
                               ported by share_nfs(1M),  but  not 
                               by mount_nfs(1M) or automount(1M). 

As an example, consider this export:

/slappy/happy -sec=krb5,rw,sec=none,rw,anon=17

This states that if a client mounts this export with krb5
(but not krb5i nor krb5p), then the user mapping is
that of the user driving the traffic.

If however, the client communicates with any other
security flavor, then the UID is always mapped to 17.

The interest here is do we want to keep this behavior
in NFSv4 and document it? Or do we want to rely on:

3.2.  Security Flavors

   Traditional RPC implementations have included AUTH_NONE, AUTH_SYS,
   AUTH_DH, and AUTH_KRB4 as security flavors.  With [4] an additional
   security flavor of RPCSEC_GSS has been introduced which uses the
   functionality of GSS-API [6].  This allows for the use of various
   security mechanisms by the RPC layer without the additional
   implementation overhead of adding RPC security flavors.  For NFSv4,
   the RPCSEC_GSS security flavor MUST be used to enable the mandatory
   security mechanism.  Other flavors, such as, AUTH_NONE, AUTH_SYS, and
   AUTH_DH MAY be implemented as well.

to allow it?

---

From: Spencer Shepler <[email-masked]>
Date: Wed, 29 Jun 2011 06:46:33 +0000

The NFSv4 documents should stand as is.  The requirement they state is
that the implementations should provide for the mandatory to implement
flavors.  How they are exposed to the user and the policies associated
with that exposure should not be part of the RFC.  If there is a desire
to document common implementation practice in an informational RFC,
that seems reasonable.

Spencer

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Thomas Haynes
> Sent: Tuesday, June 28, 2011 3:39 PM
> To: [email-masked]
> Subject: [nfsv4] Sharing with AUTH_NULL
> 
> > that returns a mount authflavor list containing an AUTH_NULL entry is
> > actually indicating it will accept any security flavor for the export
> > being mounted.
> >
> This convention is documented in both the Solaris and NetApp man pages.
> Under Solaris, nfssec(5) has this to say:
> 
> This states that if a client mounts this export with krb5 (but not krb5i
> nor krb5p), then the user mapping is that of the user driving the traffic.
> 
> If however, the client communicates with any other security flavor, then
> the UID is always mapped to 17.
> 
> The interest here is do we want to keep this behavior in NFSv4 and
> document it? Or do we want to rely on:
> 
> 3.2.  Security Flavors
> 
> _______________________________________________
> nfsv4 mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/nfsv4

---

From: "J. Bruce Fields" <[email-masked]>
Date: Wed, 29 Jun 2011 12:27:15 -0400

> to document common implementation practice in an informational RFC,

It's not just a user interface issue:

There's a protocol issue in the negotiation: is a server secinfo
response containing only "auth_null" meant to communicate that the
server won't accept krb5p?  I would have assumed so, but this precedent
from the MOUNT protocol might suggest otherwise.

Implementors might write code differently depending on the answer.

--b.

---

From: Nico Williams <[email-masked]>
Date: Wed, 29 Jun 2011 11:37:40 -0500

> from the MOUNT protocol might suggest otherwise.

What precedent?  NFSv4 doesn't depend on MOUNT in the least.
*Existing* NFSv4 clients, well, some, do.  But that says nothing about
NFSv4.

(MOUNT uses AUTH_NULL because MOUNT is dead simple.  NFSv4 does away
with MOUNT by making the share namespace part of a virtual filesystem
navigated from the ROOTFH.)

Nico
--

---

From: Spencer Shepler <[email-masked]>
Date: Wed, 29 Jun 2011 16:49:24 +0000

The server should respond with the list of acceptable security
mechanisms; the server should not respond with a partial list
assuming that the client will just figure it out.  If the
server accepts krb5p and auth_null, then they should be listed.

Spencer

> From: J. Bruce Fields [mailto:[email-masked]]
> Sent: Wednesday, June 29, 2011 9:27 AM
> To: Spencer Shepler
> Cc: Thomas Haynes; [email-masked]
> Subject: Re: [nfsv4] Sharing with AUTH_NULL
> 
> > with that exposure should not be part of the RFC.  If there is a
> > desire to document common implementation practice in an informational
> > RFC, that seems reasonable.
> 
> There's a protocol issue in the negotiation: is a server secinfo response
> containing only "auth_null" meant to communicate that the server won't
> accept krb5p?  I would have assumed so, but this precedent from the MOUNT
> protocol might suggest otherwise.
> 
> > > From: [email-masked] [mailto:[email-masked]] On
> > > Behalf Of Thomas Haynes
> > > Chuck just posted a set of changes in the way Linux clients mount
> > > under
> > > NFSv3:
> > >
> > > > traces from a NetApp filer and a Solaris NFS server) where a
> > > > server that returns a mount authflavor list containing an
> > > > AUTH_NULL entry is actually indicating it will accept any security
> > > > flavor for the export being mounted.
> > > >
> > > > This might be used when the server maps all security flavors into
> > > > the same security mode.  For example, the server treats all
> > > > accessors as, say, UID 17.
> > > >
> pages.
> > > This states that if a client mounts this export with krb5 (but not
> > > krb5i nor krb5p), then the user mapping is that of the user driving
> the traffic.
> > >
> > > If however, the client communicates with any other security flavor,
> > > then the UID is always mapped to 17.
> > >

---

From: Thomas Haynes <[email-masked]>
Date: Wed, 29 Jun 2011 11:57:19 -0500

> server accepts krb5p and auth_null, then they should be listed.

But if supporting AUTH_NULL means mapping all other variants
than krb5p to AUTH_NULL, is it correct to send back AUTH_SYS,
etc?

---

From: "J. Bruce Fields" <[email-masked]>
Date: Wed, 29 Jun 2011 13:03:38 -0400

On Wed, Jun 29, 2011 at 11:37:40AM -0500, Nico Williams wrote:
> (MOUNT uses AUTH_NULL because MOUNT is dead simple.

Sorry, there was a misunderstanding: I wasn't referring to the security
used by MOUNT calls themselves, but to the auth_flavors list in a MNT
reply.

An auth_null returned in that list apparently has had this special
meaning for some implementations.

--b.

---

From: Thomas Haynes <[email-masked]>
Date: Wed, 29 Jun 2011 12:04:19 -0500

> navigated from the ROOTFH.)

Even in NFSv3, once the MOUNT protocol is out of the way, the security
flavor is still used. Consider a malicious client that establishes a MOUNT
with krb5 and then starts sending NFSv3 traffic in AUTH_SYS. The 
server better catch that, right?

The real issue is that there are well understood semantics involving
AUTH_NULL exports in NFSv3. When a customer migrates to NFSv4,
they will expect this to still work.

---

From: Nico Williams <[email-masked]>
Date: Wed, 29 Jun 2011 12:06:22 -0500

> they will expect this to still work.

Why?  They should have to read the release notes, migration docs, ...
Better: let the vendor make it easy by translating the semantics
correctly.

---

From: "J. Bruce Fields" <[email-masked]>
Date: Wed, 29 Jun 2011 15:20:38 -0400

> Better: let the vendor make it easy by translating the semantics

Sounds reasonable.  The translation isn't absolutely perfect, because
this auth_null connection allows you to say "all other security flavors
will be mapped to an anonymous uid", whereas with secinfo you can only
say some flavors are less preferred (by sorting them to the end of the
list).  Seems close enough, though.

--b.

---

From: Trond Myklebust <[email-masked]>
Date: Wed, 29 Jun 2011 16:19:40 -0400

> Better: let the vendor make it easy by translating the semantics

I agree with Nico.

We should distinguish between the "sec=none" _export_ option, and the
actual AUTH_NULL authentication flavour as reported by MOUNT or SECINFO.

If the server wants to allow "sec=none" to mean 'I accept all flavours',
then it should translate that to a list of all the flavours that it
actually accepts, and return that list in the MOUNT or SECINFO reply.
As long as that list is properly ordered (i.e. with the unmapped
authentication security flavours first), then the client will have
enough information to make a sensible choice.

Note that it may probably makes sense to default to an implicit
"sec=none" on the pseudofilesystem so as to allow clients the same
privileges they used to have with "showmount".

Cheers,
  Trond
-- 
Trond Myklebust
Linux NFS client maintainer

NetApp
[email-masked]
www.netapp.com

---

From: Nico Williams <[email-masked]>
Date: Wed, 29 Jun 2011 15:27:11 -0500

> privileges they used to have with "showmount".

"Default" is too strong.  How about "default to allowing sec=null for
ROOTFH (and all nodes between that and shares that require better than
AUTH_NONE)"?  (That's probably what you meant, I think.)

In any case, don't REQUIRE that AUTH_NONE be available even just for
ROOTFH, right?  One might want security from the word 'go'.

Nico
--

---

From: Trond Myklebust <[email-masked]>
Date: Wed, 29 Jun 2011 16:47:36 -0400

> ROOTFH, right?  One might want security from the word 'go'.

I meant default to what we do for "showmount -e" on NFSv2/v3, which is
to allow clients to detect the actual exports.
In NFSv4 parlance, that requires the client to be able to use PUTROOTFH,
READDIR, PUTFH, GETFH, (restricted) GETATTR and LOOKUP on the pseudofs
using any security flavour. The server would squash the actual identity
to an anonymous user.
OTOH, exported sub-directories should have more restrictive security
defaults.

I do agree that the server admin SHOULD be able to set more restrictive
policies for use in insecure environments, including requiring the
client to fully auto-probe the root fh security flavour as per the
description in rfc3530.

Cheers
  Trond

NetApp

---

From: Nico Williams <[email-masked]>
Date: Wed, 29 Jun 2011 16:30:36 -0500

> using any security flavour. The server would squash the actual identity

Uh, but that's not enough.  You'd have to do the NFSv4 equivalent of a
find for directories (and files) where the fsid is different that the
parent's.  That's... not really an option (don't even think about it
:).

Basically, with pure NFSv4 there's *no* remote showmount -e.  (The
FedFS Admin protocol, OTOH, does let you do remote showmount -e,
IIRC.)

Nico
--

---

From: Thomas Haynes <[email-masked]>
Date: Wed, 29 Jun 2011 16:53:04 -0500

> enough information to make a sensible choice.

But it ins't just 'I accept all flavours', it is 'I accept all flavours and
for this subset, I will map all UIDs to be the anonymous UID'.

If we're okay with stating that the two are equal, I'm okay with
having the server return the entire list.

---

From: Trond Myklebust <[email-masked]>
Date: Wed, 29 Jun 2011 18:42:55 -0400

> for this subset, I will map all UIDs to be the anonymous UID'.

Not really. It may indeed say that 'if I accept a flavour outside of
this subset, then it is mapped', but it no longer tells you what is the
full set of supported flavours.

To me that isn't really useful information. I expect the server to give
me a list that is ordered by server administrator preference. Unless the
user explicitly requests a particular flavour on the mount command line,
then I'll choose the first flavour on that list that my client also
supports. If that happens to be AUTH_NULL, then I'll stop at that; I
won't arbitrarily decide to prefer krb5p...

> having the server return the entire list.

It would be just as easy to define the convention that 'anything that is
ordered after AUTH_NULL is a supported flavour, but all users/groups are
mapped to the anonymous user/group'. That gives you both pieces of
information, and might be worth sharing with the administrator on the
client.

That said, no matter what I do on the client, the server is free to map
my client-supplied user/group information into whatever it pleases. The
protocol does not allow me to detect root squashing, or the fact that my
user [email-masked] is actually being mapped to [email-masked] for
the purposes of ACL resolution on the server.
So why are we so concerned about supplying (only part of) that
information using a wildcard AUTH_NULL mechanism?

Cheers
  Trond

NetApp

---

From: Trond Myklebust <[email-masked]>
Date: Wed, 29 Jun 2011 19:00:40 -0400

> parent's.  That's... not really an option (don't even think about it

Why not? Creating a userland RPC client that did just that was the very
first project I gave to Bryan when he joined NetApp and was completely
unfamiliar with NFS. I won't say that it is a trivial task, but it is
certainly not beyond the capabilities of someone who is reasonably
familiar with programming. ;-)

> FedFS Admin protocol, OTOH, does let you do remote showmount -e,

I disagree; see above...

However, the other advantage of 'sec=none' is that I am then free to
mount the root fh with a whatever protocol I want, and use that protocol
to get to the exported directories. If I happen to choose krb5p, then
that gives me the full security guarantees of krb5p as I walk all the
way down to my exported fs. When I look that last component up, I may
get a WRONGSEC, but if so I can send a SECINFO using the same krb5p
security, and negotiate the required security flavour with the server.

The mapping-to-an-anonymous-user bit really doesn't matter for the
pseudofs, since that is not supposed to contain any acls.

NetApp

---

From: Nico Williams <[email-masked]>
Date: Wed, 29 Jun 2011 19:22:46 -0500

> familiar with programming. ;-)

Because back in the 90s I saw servers (v3, yeah) meltdown when too
many clients accidentally ran the same cron job to find and remove
various files from those servers.  A find with no constraints is a
very heavyweight operation for a client to run willy nilly.

A showmount command that has an option just for this that admins
understand is heavyweight is one thing.  Clients that do this as a
matter of course would be a very bad idea.  Perhaps you're only after
an admin helper tool, but even then the legacy MOUNT protocol and the
new FedFS Admin protocol would be much more efficient.  (Of course,
it's possible for a server to dynamically mount all its filesystems as
needed, in which case, and to produce the list of shares lazily too,
in which case a find would be the only viable option.  Hmmm.)

Nico
--