NFSv4 behaviour on unknown users

NFSv4 behaviour on unknown users

[Spelic]

Hello all
we recently moved to nfsv4 from v3.

I'm currently using idmapd and not kerberos.

I noticed that now, with idmapd (and with idmapd is the only way I know 
for configuring nfsv4 for now), users that are not known at server side 
are squashed to nobody / nogroup  (65534 / 65534).
And a chown by root from the client fails if the user is not known at 
server side.

That's a problem... now we need ldap everywhere...

We were often using NFS for exporting some diskspace to machines on an 
as-needed basis,
so this new behaviour complicates the things greatly for us :-/
It's almost easier to setup iSCSI targets now :-((

Is there a way to have nfsv4 with the behaviour of users of nfsv3, that 
is, using numeric IDs instead of the names, like: "nfsserver, don't care 
if you don't know the user, just give me the numeric ID for the file..."

Thank you

Re: NFSv4 behaviour on unknown users

[Simon Kirby]

On Mon, Nov 29, 2010 at 06:32:29PM +0100, Spelic wrote:

> Hello all
> we recently moved to nfsv4 from v3.
>
> I'm currently using idmapd and not kerberos.
>
> I noticed that now, with idmapd (and with idmapd is the only way I know  
> for configuring nfsv4 for now), users that are not known at server side  
> are squashed to nobody / nogroup  (65534 / 65534).
> And a chown by root from the client fails if the user is not known at  
> server side.
>
> That's a problem... now we need ldap everywhere...

Hello!

We also have a few environments using libnss-mysql currently on NFSv3,
and in this case, idmapping is pointless and just adds useless work,
since all of the clients already have exactly the same user mappings, by
design.  In fact, the NFS servers don't even know about the users for the
files they serve, and this is fine.  We'd have to set up libnss-mysql
on them for NFSv4 to work, all just so NFSv4 can have names on the wire.

This came up before; e.g. http://linux.derkeiler.com/Mailing-Lists/Kernel/2009-09/msg01071.html
(I hijacked the thread about the credcache hash bucket size, which is
also an issue we ran into as well, but which also affects NFSv3.)

I tried to write the NFSv4 spec people, but didn't get any reply.  I can
see maybe why they would want to do this by default, but it's not like
people don't already have years of experience with how NFSv3 and earlier
worked, and I still think should at least be a way to request that
behaviour.

Simon-

Re: NFSv4 behaviour on unknown users

[Spelic]

On 11/29/2010 08:50 PM, Simon Kirby wrote:
> ...
> I tried to write the NFSv4 spec people, but didn't get any reply.  I can
> see maybe why they would want to do this by default, but it's not like
> people don't already have years of experience with how NFSv3 and earlier
> worked, and I still think should at least be a way to request that
> behaviour.
>    

Yeah!!!
currently it sucks... er...
I don't understand... never before I came across a "new version" of a 
software or a protocol which allows to do many fewer things than the 
older version. This sucks. Lots of use cases for NFS here are totally lost.

I'm thinking that even if I'd setup LDAP for everything here, things 
would not be easy, because we have server1 which has certain users and 
groups, server2+server3 which are for a different project and have 
different users and groups etc... and now we need to have the NFS server 
understand all those sets of users simultaneously, but the various 
servers only need to understand theirs and the other people should not 
be able to log in!
Maybe it's possible (I don't know how), but looks like a major headache. 
And now we probably cannot even have more than one LDAP server any 
longer: all LDAP probably needs to be centralized on a single machine 
which is where the NFS server(s) authenticate... it looks like a real 
problem for the independence of projects... and I really fear to think 
of what will happen if that machine fails!

I'd be glad to go back to NFS version 3 but we need nfs on infiniband 
rdma now, and afaik it's only available in version 4.

If it's still possible to change the specs or break them, well... you 
sure have my vote!

Thank you
S.

Re: NFSv4 behaviour on unknown users

[Chuck Lever]

On Nov 29, 2010, at 5:47 PM, Spelic wrote:

> I'd be glad to go back to NFS version 3 but we need nfs on infiniband rdma now, and afaik it's only available in version 4.

NFS/RDMA is also available for NFSv3, in fact that's where it was first fully implemented.  Whether it is well-supported upstream is another question entirely.

-- 
Chuck Lever
chuck[dot]lever[at]oracle[dot]com

NFSv4 behaviour on unknown users

[Spelic]

Hello all
we recently moved to nfsv4 from v3.

I'm currently using idmapd and not kerberos.

I noticed that now, with idmapd (and with idmapd is the only way I know 
for configuring nfsv4 for now), users that are not known at server side 
are squashed to nobody / nogroup  (65534 / 65534).
And a chown by root from the client fails if the user is not known at 
server side.

That's a problem... now we need ldap everywhere...

We were often using NFS for exporting some diskspace to machines on an 
as-needed basis,
so this new behaviour complicates the things greatly for us :-/
It's almost easier to setup iSCSI targets now :-((

Is there a way to have nfsv4 with the behaviour of users of nfsv3, that 
is, using numeric IDs instead of the names, like: "nfsserver, don't care 
if you don't know the user, just give me the numeric ID for the file..."

Thank you

Re: NFSv4 behaviour on unknown users

[Trond Myklebust]

On Mon, 2010-11-29 at 19:12 +0100, Spelic wrote:
> Hello all
> we recently moved to nfsv4 from v3.
> 
> I'm currently using idmapd and not kerberos.
> 
> I noticed that now, with idmapd (and with idmapd is the only way I know 
> for configuring nfsv4 for now), users that are not known at server side 
> are squashed to nobody / nogroup  (65534 / 65534).
> And a chown by root from the client fails if the user is not known at 
> server side.
> 
> That's a problem... now we need ldap everywhere...
> 
> We were often using NFS for exporting some diskspace to machines on an 
> as-needed basis,
> so this new behaviour complicates the things greatly for us :-/
> It's almost easier to setup iSCSI targets now :-((
> 
> Is there a way to have nfsv4 with the behaviour of users of nfsv3, that 
> is, using numeric IDs instead of the names, like: "nfsserver, don't care 
> if you don't know the user, just give me the numeric ID for the file..."

No. That is not allowed by the spec.

Trond
-- 
Trond Myklebust
Linux NFS client maintainer

NetApp
Trond.Myklebust@netapp.com
www.netapp.com

Re: NFSv4 behaviour on unknown users

[Spelic]

On 11/29/2010 07:22 PM, Trond Myklebust wrote:
> On Mon, 2010-11-29 at 19:12 +0100, Spelic wrote:
>    
> No. That is not allowed by the spec.
>
> Trond
>    

Too bad!! :-((
Was that spec decision really wise? :-/


BTW:
I've just noticed two discussions dated a few months ago in this ML 
regarding this.
the thread named 'numeric UIDs'
and more interestingly the thread: "Teach clients to map numeric strings 
into valid uids and gids."
http://marc.info/?t=128207393000001&r=1&w=2

Would the patch by Steve Dickson allow us to have numeric UID mapping 
like in NFSv3?
(Including ability for a non-squashed-root to do chown towards an UID 
which is unknown at server side)

And if yes, how come this is not against the specs?

Thank you

Re: NFSv4 behaviour on unknown users

[J. Bruce Fields]

On Mon, Nov 29, 2010 at 07:38:30PM +0100, Spelic wrote:
> On 11/29/2010 07:22 PM, Trond Myklebust wrote:
> >On Mon, 2010-11-29 at 19:12 +0100, Spelic wrote:
> >No. That is not allowed by the spec.
> >
> >Trond
> 
> Too bad!! :-((
> Was that spec decision really wise? :-/
> 
> 
> BTW:
> I've just noticed two discussions dated a few months ago in this ML
> regarding this.
> the thread named 'numeric UIDs'

There's also a reference to the spec language there--we'd be violating a
"SHOULD", but I think it would be acceptable if it smooths the v3->v4
upgrade path for users in your situation.

I think steved's changes still need to be ported to libnfsidmap?

--b.

> and more interestingly the thread: "Teach clients to map numeric
> strings into valid uids and gids."
> http://marc.info/?t=128207393000001&r=1&w=2
> 
> Would the patch by Steve Dickson allow us to have numeric UID
> mapping like in NFSv3?
> (Including ability for a non-squashed-root to do chown towards an
> UID which is unknown at server side)
> 
> And if yes, how come this is not against the specs?
> 
> Thank you
> --
> To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: NFSv4 behaviour on unknown users

[Trond Myklebust]

On Mon, 2010-11-29 at 14:01 -0500, J. Bruce Fields wrote:
> On Mon, Nov 29, 2010 at 07:38:30PM +0100, Spelic wrote:
> > On 11/29/2010 07:22 PM, Trond Myklebust wrote:
> > >On Mon, 2010-11-29 at 19:12 +0100, Spelic wrote:
> > >No. That is not allowed by the spec.
> > >
> > >Trond
> > 
> > Too bad!! :-((
> > Was that spec decision really wise? :-/
> > 
> > 
> > BTW:
> > I've just noticed two discussions dated a few months ago in this ML
> > regarding this.
> > the thread named 'numeric UIDs'
> 
> There's also a reference to the spec language there--we'd be violating a
> "SHOULD", but I think it would be acceptable if it smooths the v3->v4
> upgrade path for users in your situation.
> 
> I think steved's changes still need to be ported to libnfsidmap?

I don't see how steved's changes will fix this problem. If the client
has a mapping, it will (MUST) send the mapped uid/gid and the server
still has to make sense of that. Ditto if the server has a mapping, and
the client does not.

steved's patches only help if neither the client nor the server can map
the uid/gids to a name@domain format.

Trond

> --b.
> 
> > and more interestingly the thread: "Teach clients to map numeric
> > strings into valid uids and gids."
> > http://marc.info/?t=128207393000001&r=1&w=2
> > 
> > Would the patch by Steve Dickson allow us to have numeric UID
> > mapping like in NFSv3?
> > (Including ability for a non-squashed-root to do chown towards an
> > UID which is unknown at server side)
> > 
> > And if yes, how come this is not against the specs?
> > 
> > Thank you
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> --
> To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

-- 
Trond Myklebust
Linux NFS client maintainer

NetApp
Trond.Myklebust@netapp.com
www.netapp.com

Re: NFSv4 behaviour on unknown users

[Steve Dickson]

On 11/29/2010 02:09 PM, Trond Myklebust wrote:
> On Mon, 2010-11-29 at 14:01 -0500, J. Bruce Fields wrote:
>> On Mon, Nov 29, 2010 at 07:38:30PM +0100, Spelic wrote:
>>> On 11/29/2010 07:22 PM, Trond Myklebust wrote:
>>>> On Mon, 2010-11-29 at 19:12 +0100, Spelic wrote:
>>>> No. That is not allowed by the spec.
>>>>
>>>> Trond
>>>
>>> Too bad!! :-((
>>> Was that spec decision really wise? :-/
>>>
>>>
>>> BTW:
>>> I've just noticed two discussions dated a few months ago in this ML
>>> regarding this.
>>> the thread named 'numeric UIDs'
>>
>> There's also a reference to the spec language there--we'd be violating a
>> "SHOULD", but I think it would be acceptable if it smooths the v3->v4
>> upgrade path for users in your situation.
>>
>> I think steved's changes still need to be ported to libnfsidmap?
> 
> I don't see how steved's changes will fix this problem. If the client
> has a mapping, it will (MUST) send the mapped uid/gid and the server
> still has to make sense of that. Ditto if the server has a mapping, and
> the client does not.
I actually thought it did... 

Now that the libnfsidmap maintainership has been handed over to me 
and I'm about to enable the new nfsidmapper when I commit the 
"libnfsidmap: Add numerical string translation" patch... Its 
probably time I take a second look at those patches to see
if we can ease some of this pain...

steved.

Re: NFSv4 behaviour on unknown users

[Trond Myklebust]

On Tue, 2010-11-30 at 10:36 -0500, Steve Dickson wrote:
> 
> On 11/29/2010 02:09 PM, Trond Myklebust wrote:
> > On Mon, 2010-11-29 at 14:01 -0500, J. Bruce Fields wrote:
> >> On Mon, Nov 29, 2010 at 07:38:30PM +0100, Spelic wrote:
> >>> On 11/29/2010 07:22 PM, Trond Myklebust wrote:
> >>>> On Mon, 2010-11-29 at 19:12 +0100, Spelic wrote:
> >>>> No. That is not allowed by the spec.
> >>>>
> >>>> Trond
> >>>
> >>> Too bad!! :-((
> >>> Was that spec decision really wise? :-/
> >>>
> >>>
> >>> BTW:
> >>> I've just noticed two discussions dated a few months ago in this ML
> >>> regarding this.
> >>> the thread named 'numeric UIDs'
> >>
> >> There's also a reference to the spec language there--we'd be violating a
> >> "SHOULD", but I think it would be acceptable if it smooths the v3->v4
> >> upgrade path for users in your situation.
> >>
> >> I think steved's changes still need to be ported to libnfsidmap?
> > 
> > I don't see how steved's changes will fix this problem. If the client
> > has a mapping, it will (MUST) send the mapped uid/gid and the server
> > still has to make sense of that. Ditto if the server has a mapping, and
> > the client does not.
> I actually thought it did... 

How? The userland library has no concept of whether or not the server
accepts unmapped uids and gids.

> Now that the libnfsidmap maintainership has been handed over to me 
> and I'm about to enable the new nfsidmapper when I commit the 
> "libnfsidmap: Add numerical string translation" patch... Its 
> probably time I take a second look at those patches to see
> if we can ease some of this pain...

Some reasons for doing this in the kernel are:

1) it is easy to do so.
2) it allows the kernel to take action to recover
3) it fixes the nfsroot problem, provided that the server also sends
uids/gids in this situation.

-- 
Trond Myklebust
Linux NFS client maintainer

NetApp
Trond.Myklebust@netapp.com
www.netapp.com

Re: NFSv4 behaviour on unknown users

[J. Bruce Fields]

On Tue, Nov 30, 2010 at 05:19:38PM -0500, Trond Myklebust wrote:
> On Tue, 2010-11-30 at 10:36 -0500, Steve Dickson wrote:
> > 
> > On 11/29/2010 02:09 PM, Trond Myklebust wrote:
> > > On Mon, 2010-11-29 at 14:01 -0500, J. Bruce Fields wrote:
> > >> On Mon, Nov 29, 2010 at 07:38:30PM +0100, Spelic wrote:
> > >>> On 11/29/2010 07:22 PM, Trond Myklebust wrote:
> > >>>> On Mon, 2010-11-29 at 19:12 +0100, Spelic wrote:
> > >>>> No. That is not allowed by the spec.
> > >>>>
> > >>>> Trond
> > >>>
> > >>> Too bad!! :-((
> > >>> Was that spec decision really wise? :-/
> > >>>
> > >>>
> > >>> BTW:
> > >>> I've just noticed two discussions dated a few months ago in this ML
> > >>> regarding this.
> > >>> the thread named 'numeric UIDs'
> > >>
> > >> There's also a reference to the spec language there--we'd be violating a
> > >> "SHOULD", but I think it would be acceptable if it smooths the v3->v4
> > >> upgrade path for users in your situation.
> > >>
> > >> I think steved's changes still need to be ported to libnfsidmap?
> > > 
> > > I don't see how steved's changes will fix this problem. If the client
> > > has a mapping, it will (MUST) send the mapped uid/gid and the server
> > > still has to make sense of that. Ditto if the server has a mapping, and
> > > the client does not.
> > I actually thought it did... 
> 
> How? The userland library has no concept of whether or not the server
> accepts unmapped uids and gids.
> 
> > Now that the libnfsidmap maintainership has been handed over to me 
> > and I'm about to enable the new nfsidmapper when I commit the 
> > "libnfsidmap: Add numerical string translation" patch... Its 
> > probably time I take a second look at those patches to see
> > if we can ease some of this pain...
> 
> Some reasons for doing this in the kernel are:
> 
> 1) it is easy to do so.
> 2) it allows the kernel to take action to recover
> 3) it fixes the nfsroot problem, provided that the server also sends
> uids/gids in this situation.

Makes sense to me.

The server side might still be easiest to do in idmapd/libnfsidmap.

--b.

Re: NFSv4 behaviour on unknown users

[Trond Myklebust]

On Tue, 2010-11-30 at 17:26 -0500, J. Bruce Fields wrote:
> On Tue, Nov 30, 2010 at 05:19:38PM -0500, Trond Myklebust wrote:
> > On Tue, 2010-11-30 at 10:36 -0500, Steve Dickson wrote:
> > > 
> > > On 11/29/2010 02:09 PM, Trond Myklebust wrote:
> > > > On Mon, 2010-11-29 at 14:01 -0500, J. Bruce Fields wrote:
> > > >> On Mon, Nov 29, 2010 at 07:38:30PM +0100, Spelic wrote:
> > > >>> On 11/29/2010 07:22 PM, Trond Myklebust wrote:
> > > >>>> On Mon, 2010-11-29 at 19:12 +0100, Spelic wrote:
> > > >>>> No. That is not allowed by the spec.
> > > >>>>
> > > >>>> Trond
> > > >>>
> > > >>> Too bad!! :-((
> > > >>> Was that spec decision really wise? :-/
> > > >>>
> > > >>>
> > > >>> BTW:
> > > >>> I've just noticed two discussions dated a few months ago in this ML
> > > >>> regarding this.
> > > >>> the thread named 'numeric UIDs'
> > > >>
> > > >> There's also a reference to the spec language there--we'd be violating a
> > > >> "SHOULD", but I think it would be acceptable if it smooths the v3->v4
> > > >> upgrade path for users in your situation.
> > > >>
> > > >> I think steved's changes still need to be ported to libnfsidmap?
> > > > 
> > > > I don't see how steved's changes will fix this problem. If the client
> > > > has a mapping, it will (MUST) send the mapped uid/gid and the server
> > > > still has to make sense of that. Ditto if the server has a mapping, and
> > > > the client does not.
> > > I actually thought it did... 
> > 
> > How? The userland library has no concept of whether or not the server
> > accepts unmapped uids and gids.
> > 
> > > Now that the libnfsidmap maintainership has been handed over to me 
> > > and I'm about to enable the new nfsidmapper when I commit the 
> > > "libnfsidmap: Add numerical string translation" patch... Its 
> > > probably time I take a second look at those patches to see
> > > if we can ease some of this pain...
> > 
> > Some reasons for doing this in the kernel are:
> > 
> > 1) it is easy to do so.
> > 2) it allows the kernel to take action to recover
> > 3) it fixes the nfsroot problem, provided that the server also sends
> > uids/gids in this situation.
> 
> Makes sense to me.
> 
> The server side might still be easiest to do in idmapd/libnfsidmap.

The NFS server has to be able to tell the idmapper which variety of
mapping it wants. The reason is, as I said, that we want to handle
RPCSEC_GSS based authentication (and possibly AUTH_NULL too) differently
from AUTH_SYS. The idmapper by itself has no way to distinguish what
authentication the client used.

-- 
Trond Myklebust
Linux NFS client maintainer

NetApp
Trond.Myklebust@netapp.com
www.netapp.com

Re: NFSv4 behaviour on unknown users

[J. Bruce Fields]

On Tue, Nov 30, 2010 at 05:33:34PM -0500, Trond Myklebust wrote:
> On Tue, 2010-11-30 at 17:26 -0500, J. Bruce Fields wrote:
> > On Tue, Nov 30, 2010 at 05:19:38PM -0500, Trond Myklebust wrote:
> > > On Tue, 2010-11-30 at 10:36 -0500, Steve Dickson wrote:
> > > > 
> > > > On 11/29/2010 02:09 PM, Trond Myklebust wrote:
> > > > > On Mon, 2010-11-29 at 14:01 -0500, J. Bruce Fields wrote:
> > > > >> On Mon, Nov 29, 2010 at 07:38:30PM +0100, Spelic wrote:
> > > > >>> On 11/29/2010 07:22 PM, Trond Myklebust wrote:
> > > > >>>> On Mon, 2010-11-29 at 19:12 +0100, Spelic wrote:
> > > > >>>> No. That is not allowed by the spec.
> > > > >>>>
> > > > >>>> Trond
> > > > >>>
> > > > >>> Too bad!! :-((
> > > > >>> Was that spec decision really wise? :-/
> > > > >>>
> > > > >>>
> > > > >>> BTW:
> > > > >>> I've just noticed two discussions dated a few months ago in this ML
> > > > >>> regarding this.
> > > > >>> the thread named 'numeric UIDs'
> > > > >>
> > > > >> There's also a reference to the spec language there--we'd be violating a
> > > > >> "SHOULD", but I think it would be acceptable if it smooths the v3->v4
> > > > >> upgrade path for users in your situation.
> > > > >>
> > > > >> I think steved's changes still need to be ported to libnfsidmap?
> > > > > 
> > > > > I don't see how steved's changes will fix this problem. If the client
> > > > > has a mapping, it will (MUST) send the mapped uid/gid and the server
> > > > > still has to make sense of that. Ditto if the server has a mapping, and
> > > > > the client does not.
> > > > I actually thought it did... 
> > > 
> > > How? The userland library has no concept of whether or not the server
> > > accepts unmapped uids and gids.
> > > 
> > > > Now that the libnfsidmap maintainership has been handed over to me 
> > > > and I'm about to enable the new nfsidmapper when I commit the 
> > > > "libnfsidmap: Add numerical string translation" patch... Its 
> > > > probably time I take a second look at those patches to see
> > > > if we can ease some of this pain...
> > > 
> > > Some reasons for doing this in the kernel are:
> > > 
> > > 1) it is easy to do so.
> > > 2) it allows the kernel to take action to recover
> > > 3) it fixes the nfsroot problem, provided that the server also sends
> > > uids/gids in this situation.
> > 
> > Makes sense to me.
> > 
> > The server side might still be easiest to do in idmapd/libnfsidmap.
> 
> The NFS server has to be able to tell the idmapper which variety of
> mapping it wants. The reason is, as I said, that we want to handle
> RPCSEC_GSS based authentication (and possibly AUTH_NULL too) differently
> from AUTH_SYS. The idmapper by itself has no way to distinguish what
> authentication the client used.

I still don't understand what the advantage of that would be: why would
we want to return different file owners depending on which
authentication flavor the client's request used?

--b.

Re: NFSv4 behaviour on unknown users

[Trond Myklebust]

On Tue, 2010-11-30 at 17:36 -0500, J. Bruce Fields wrote:
> On Tue, Nov 30, 2010 at 05:33:34PM -0500, Trond Myklebust wrote:
> > On Tue, 2010-11-30 at 17:26 -0500, J. Bruce Fields wrote:
> > > On Tue, Nov 30, 2010 at 05:19:38PM -0500, Trond Myklebust wrote:
> > > > On Tue, 2010-11-30 at 10:36 -0500, Steve Dickson wrote:
> > > > > 
> > > > > On 11/29/2010 02:09 PM, Trond Myklebust wrote:
> > > > > > On Mon, 2010-11-29 at 14:01 -0500, J. Bruce Fields wrote:
> > > > > >> On Mon, Nov 29, 2010 at 07:38:30PM +0100, Spelic wrote:
> > > > > >>> On 11/29/2010 07:22 PM, Trond Myklebust wrote:
> > > > > >>>> On Mon, 2010-11-29 at 19:12 +0100, Spelic wrote:
> > > > > >>>> No. That is not allowed by the spec.
> > > > > >>>>
> > > > > >>>> Trond
> > > > > >>>
> > > > > >>> Too bad!! :-((
> > > > > >>> Was that spec decision really wise? :-/
> > > > > >>>
> > > > > >>>
> > > > > >>> BTW:
> > > > > >>> I've just noticed two discussions dated a few months ago in this ML
> > > > > >>> regarding this.
> > > > > >>> the thread named 'numeric UIDs'
> > > > > >>
> > > > > >> There's also a reference to the spec language there--we'd be violating a
> > > > > >> "SHOULD", but I think it would be acceptable if it smooths the v3->v4
> > > > > >> upgrade path for users in your situation.
> > > > > >>
> > > > > >> I think steved's changes still need to be ported to libnfsidmap?
> > > > > > 
> > > > > > I don't see how steved's changes will fix this problem. If the client
> > > > > > has a mapping, it will (MUST) send the mapped uid/gid and the server
> > > > > > still has to make sense of that. Ditto if the server has a mapping, and
> > > > > > the client does not.
> > > > > I actually thought it did... 
> > > > 
> > > > How? The userland library has no concept of whether or not the server
> > > > accepts unmapped uids and gids.
> > > > 
> > > > > Now that the libnfsidmap maintainership has been handed over to me 
> > > > > and I'm about to enable the new nfsidmapper when I commit the 
> > > > > "libnfsidmap: Add numerical string translation" patch... Its 
> > > > > probably time I take a second look at those patches to see
> > > > > if we can ease some of this pain...
> > > > 
> > > > Some reasons for doing this in the kernel are:
> > > > 
> > > > 1) it is easy to do so.
> > > > 2) it allows the kernel to take action to recover
> > > > 3) it fixes the nfsroot problem, provided that the server also sends
> > > > uids/gids in this situation.
> > > 
> > > Makes sense to me.
> > > 
> > > The server side might still be easiest to do in idmapd/libnfsidmap.
> > 
> > The NFS server has to be able to tell the idmapper which variety of
> > mapping it wants. The reason is, as I said, that we want to handle
> > RPCSEC_GSS based authentication (and possibly AUTH_NULL too) differently
> > from AUTH_SYS. The idmapper by itself has no way to distinguish what
> > authentication the client used.
> 
> I still don't understand what the advantage of that would be: why would
> we want to return different file owners depending on which
> authentication flavor the client's request used?

If the client uses AUTH_GSS, then the user gets authorised as user@FOO,
whether or not the server uid matches that of the client. When that user
creates a file, then the file will be created with the server's notion
of what the uid is, so you _want_ idmapping in order to translate that
into a user@foo that the client can translate back into its notion of
the uid.

If the client uses AUTH_SYS, then the user gets authorised as 'client
uid' irrespective of what user@foo maps to on the server. Files will be
created with 'client uid' as the owner. In that case, having the server
translate the owner to 'userbar@foo' is wrong if userbar@foo has a
different uid on the client and server.

Trond

-- 
Trond Myklebust
Linux NFS client maintainer

NetApp
Trond.Myklebust@netapp.com
www.netapp.com

Re: NFSv4 behaviour on unknown users

[Neil Brown]

On Tue, 30 Nov 2010 17:36:27 -0500 "J. Bruce Fields" <bfields@fieldses.org>
wrote:

> On Tue, Nov 30, 2010 at 05:33:34PM -0500, Trond Myklebust wrote:
> > On Tue, 2010-11-30 at 17:26 -0500, J. Bruce Fields wrote:
> > > On Tue, Nov 30, 2010 at 05:19:38PM -0500, Trond Myklebust wrote:
....
> > > > Some reasons for doing this in the kernel are:
> > > > 
> > > > 1) it is easy to do so.
> > > > 2) it allows the kernel to take action to recover
> > > > 3) it fixes the nfsroot problem, provided that the server also sends
> > > > uids/gids in this situation.
> > > 
> > > Makes sense to me.
> > > 
> > > The server side might still be easiest to do in idmapd/libnfsidmap.
> > 
> > The NFS server has to be able to tell the idmapper which variety of
> > mapping it wants. The reason is, as I said, that we want to handle
> > RPCSEC_GSS based authentication (and possibly AUTH_NULL too) differently
> > from AUTH_SYS. The idmapper by itself has no way to distinguish what
> > authentication the client used.
> 
> I still don't understand what the advantage of that would be: why would
> we want to return different file owners depending on which
> authentication flavor the client's request used?
> 

I have a strong memory from about 7 years ago of Brian Pawlowski saying - or
possibly being quoted as saying - that the user information in NFS requests
(the stuff that idmapper handles) is totally independent of the RPC
authentication mechanism being used (the AUTH_SYS / RPCSEC_GSS stuff).

I always thought that was nonsense, but I wasn't in a position to discuss it
at the time for reasons that I really don't recall.

If users are being authorised using numbers (AUTH_SYS) then it only (to me)
makes sense to communication all identies as numbers.
And if users are being authenticated as name@domain strings, then it only
make sense to communicate all identities as name@domain.

But this path is not the path for NFSv4 followed.

I've very glad to see Linux NFS allowing numeric IDs "on the wire" and hope
to see this very sensible approach widely adopted (where AUTH_SYS is used).
I think it would be great if nfsd did the same thing completely in-kernel
without reference to idmapd.  Accepting either numeric or domain-based is
trivial.  Choosing which to send on a per-client basis might be a challenge,
but probably not a big one.


I wonder if Brian remembers saying anything like that...

NeilBrown


> --b.
> --
> To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: NFSv4 behaviour on unknown users

[Trond Myklebust]

On Wed, 2010-12-01 at 13:57 +1100, Neil Brown wrote:
> I have a strong memory from about 7 years ago of Brian Pawlowski saying - or
> possibly being quoted as saying - that the user information in NFS requests
> (the stuff that idmapper handles) is totally independent of the RPC
> authentication mechanism being used (the AUTH_SYS / RPCSEC_GSS stuff).
> 
> I always thought that was nonsense, but I wasn't in a position to discuss it
> at the time for reasons that I really don't recall.
> 
> If users are being authorised using numbers (AUTH_SYS) then it only (to me)
> makes sense to communication all identies as numbers.
> And if users are being authenticated as name@domain strings, then it only
> make sense to communicate all identities as name@domain.
> 
> But this path is not the path for NFSv4 followed.
> 
> I've very glad to see Linux NFS allowing numeric IDs "on the wire" and hope
> to see this very sensible approach widely adopted (where AUTH_SYS is used).
> I think it would be great if nfsd did the same thing completely in-kernel
> without reference to idmapd.  Accepting either numeric or domain-based is
> trivial.  Choosing which to send on a per-client basis might be a challenge,
> but probably not a big one.
> 
> 
> I wonder if Brian remembers saying anything like that...

I think you need to take beepy's words in context here: as I believe I
mentioned previously, RFC3530 (and its predecessor RFC3010) assumed
everyone would be using principals for authenticating, either through
RPCSEC_GSS w/ krb5, or through the SPKM/Lipkey mechanism. So sure was
everyone of this, that AUTH_SYS isn't even mentioned as a valid
authentication mechanism, and so nobody had to worry about the
consequences of using it.

The fact we still use AUTH_SYS today is, BTW, very much a result of the
failure of SPKM/Lipkey to deliver on its promise of strong
authentication with no extra infrastructure requirements. If it had, we
wouldn't be needing this hack.

Cheers
  Trond

-- 
Trond Myklebust
Linux NFS client maintainer

NetApp
Trond.Myklebust@netapp.com
www.netapp.com

Re: NFSv4 behaviour on unknown users

[Neil Brown]

On Tue, 30 Nov 2010 22:10:02 -0500 Trond Myklebust
<Trond.Myklebust@netapp.com> wrote:

> On Wed, 2010-12-01 at 13:57 +1100, Neil Brown wrote:
> > I have a strong memory from about 7 years ago of Brian Pawlowski saying - or
> > possibly being quoted as saying - that the user information in NFS requests
> > (the stuff that idmapper handles) is totally independent of the RPC
> > authentication mechanism being used (the AUTH_SYS / RPCSEC_GSS stuff).
> > 
> > I always thought that was nonsense, but I wasn't in a position to discuss it
> > at the time for reasons that I really don't recall.
> > 
> > If users are being authorised using numbers (AUTH_SYS) then it only (to me)
> > makes sense to communication all identies as numbers.
> > And if users are being authenticated as name@domain strings, then it only
> > make sense to communicate all identities as name@domain.
> > 
> > But this path is not the path for NFSv4 followed.
> > 
> > I've very glad to see Linux NFS allowing numeric IDs "on the wire" and hope
> > to see this very sensible approach widely adopted (where AUTH_SYS is used).
> > I think it would be great if nfsd did the same thing completely in-kernel
> > without reference to idmapd.  Accepting either numeric or domain-based is
> > trivial.  Choosing which to send on a per-client basis might be a challenge,
> > but probably not a big one.
> > 
> > 
> > I wonder if Brian remembers saying anything like that...
> 
> I think you need to take beepy's words in context here: as I believe I
> mentioned previously, RFC3530 (and its predecessor RFC3010) assumed
> everyone would be using principals for authenticating, either through
> RPCSEC_GSS w/ krb5, or through the SPKM/Lipkey mechanism. So sure was
> everyone of this, that AUTH_SYS isn't even mentioned as a valid
> authentication mechanism, and so nobody had to worry about the
> consequences of using it.
> 
> The fact we still use AUTH_SYS today is, BTW, very much a result of the
> failure of SPKM/Lipkey to deliver on its promise of strong
> authentication with no extra infrastructure requirements. If it had, we
> wouldn't be needing this hack.

Thanks Trond.  You are undoubtedly right, and that does make the comment a
little less strange.
Though I still think that LIPKEY and krb5 are different identification
mechanisms and so assuming that the identities are in the same namespace is
wrong.  Obviously it is possibly to force them to be in the same namespace,
but building that into the protocol as an assumption just seems wrong.

Thanks,
NeilBrown

Re: NFSv4 behaviour on unknown users

[J. Bruce Fields]

On Tue, Nov 30, 2010 at 10:10:02PM -0500, Trond Myklebust wrote:
> On Wed, 2010-12-01 at 13:57 +1100, Neil Brown wrote:
> > I have a strong memory from about 7 years ago of Brian Pawlowski saying - or
> > possibly being quoted as saying - that the user information in NFS requests
> > (the stuff that idmapper handles) is totally independent of the RPC
> > authentication mechanism being used (the AUTH_SYS / RPCSEC_GSS stuff).
> > 
> > I always thought that was nonsense, but I wasn't in a position to discuss it
> > at the time for reasons that I really don't recall.
> > 
> > If users are being authorised using numbers (AUTH_SYS) then it only (to me)
> > makes sense to communication all identies as numbers.
> > And if users are being authenticated as name@domain strings, then it only
> > make sense to communicate all identities as name@domain.
> > 
> > But this path is not the path for NFSv4 followed.
> > 
> > I've very glad to see Linux NFS allowing numeric IDs "on the wire" and hope
> > to see this very sensible approach widely adopted (where AUTH_SYS is used).
> > I think it would be great if nfsd did the same thing completely in-kernel
> > without reference to idmapd.  Accepting either numeric or domain-based is
> > trivial.  Choosing which to send on a per-client basis might be a challenge,
> > but probably not a big one.
> > 
> > 
> > I wonder if Brian remembers saying anything like that...
> 
> I think you need to take beepy's words in context here: as I believe I
> mentioned previously, RFC3530 (and its predecessor RFC3010) assumed
> everyone would be using principals for authenticating, either through
> RPCSEC_GSS w/ krb5, or through the SPKM/Lipkey mechanism. So sure was
> everyone of this, that AUTH_SYS isn't even mentioned as a valid
> authentication mechanism, and so nobody had to worry about the
> consequences of using it.

I also wonder whether the value of a transparent upgrade from NFSv3 got
a little lost.

To me that seems like the first requirement for version n+1 of
anything--that we should be able to upgrade people to version n without
their noticing.

Maybe there are features that are necessarily incompatible, and that
merit the downside, but the downside--losing the chance to get new
features to every user automatically--seems significant to me.


And, perhaps it's a disease, but I have gotten into the habit of
thinking of the (krb5 principal)->(id, gid's) mapping as independent of
the (NFSv4 user name)<->(uid) and (NFSv4 group name)<->(gid) mappings.

Granted they have to be coordinated on any reasonably complicated setup.
But there are simple cases where they don't necessarily need to be.

E.g. on a dumb "cp -ax / /nfs" backup it doesn't really matter "who"
does the backup as long as they have sufficient permissions, since the
files will all be explicitly chown'd as they're created.  And with krb5
it's simple enough to make that work with a single static mapping from a
client-side principal to root on the server.

And, again, that's something that works now with NFSv3.

--b.

Re: NFSv4 behaviour on unknown users

[Thomas Haynes]

On Dec 1, 2010, at 10:29 AM, J. Bruce Fields wrote:

> On Tue, Nov 30, 2010 at 10:10:02PM -0500, Trond Myklebust wrote:
>> 
>> I think you need to take beepy's words in context here: as I believe I
>> mentioned previously, RFC3530 (and its predecessor RFC3010) assumed
>> everyone would be using principals for authenticating, either through
>> RPCSEC_GSS w/ krb5, or through the SPKM/Lipkey mechanism. So sure was
>> everyone of this, that AUTH_SYS isn't even mentioned as a valid
>> authentication mechanism, and so nobody had to worry about the
>> consequences of using it.
> 
> I also wonder whether the value of a transparent upgrade from NFSv3 got
> a little lost.
> 
> To me that seems like the first requirement for version n+1 of
> anything--that we should be able to upgrade people to version n without
> their noticing.
> 
> Maybe there are features that are necessarily incompatible, and that
> merit the downside, but the downside--losing the chance to get new
> features to every user automatically--seems significant to me.
> 
> 
> And, perhaps it's a disease, but I have gotten into the habit of
> thinking of the (krb5 principal)->(id, gid's) mapping as independent of
> the (NFSv4 user name)<->(uid) and (NFSv4 group name)<->(gid) mappings.
> 
> Granted they have to be coordinated on any reasonably complicated setup.
> But there are simple cases where they don't necessarily need to be.
> 
> E.g. on a dumb "cp -ax / /nfs" backup it doesn't really matter "who"
> does the backup as long as they have sufficient permissions, since the
> files will all be explicitly chown'd as they're created.  And with krb5
> it's simple enough to make that work with a single static mapping from a
> client-side principal to root on the server.
> 
> And, again, that's something that works now with NFSv3.
> 
> --b.
> --
> To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html


Another question is whether or not such an approach would be appreciated
as part of 3530bis?

I.e., we don't have to change the over-the-wire protocol, but via a consistent
interpretation, all clients and servers can offer a smoother NFSv3 -> NFSv4.x
upgrade path.

Re: NFSv4 behaviour on unknown users

[Trond Myklebust]

On Thu, 2010-12-02 at 17:10 -0600, Thomas Haynes wrote:
> On Dec 1, 2010, at 10:29 AM, J. Bruce Fields wrote:
> 
> > On Tue, Nov 30, 2010 at 10:10:02PM -0500, Trond Myklebust wrote:
> >> 
> >> I think you need to take beepy's words in context here: as I believe I
> >> mentioned previously, RFC3530 (and its predecessor RFC3010) assumed
> >> everyone would be using principals for authenticating, either through
> >> RPCSEC_GSS w/ krb5, or through the SPKM/Lipkey mechanism. So sure was
> >> everyone of this, that AUTH_SYS isn't even mentioned as a valid
> >> authentication mechanism, and so nobody had to worry about the
> >> consequences of using it.
> > 
> > I also wonder whether the value of a transparent upgrade from NFSv3 got
> > a little lost.
> > 
> > To me that seems like the first requirement for version n+1 of
> > anything--that we should be able to upgrade people to version n without
> > their noticing.
> > 
> > Maybe there are features that are necessarily incompatible, and that
> > merit the downside, but the downside--losing the chance to get new
> > features to every user automatically--seems significant to me.
> > 
> > 
> > And, perhaps it's a disease, but I have gotten into the habit of
> > thinking of the (krb5 principal)->(id, gid's) mapping as independent of
> > the (NFSv4 user name)<->(uid) and (NFSv4 group name)<->(gid) mappings.
> > 
> > Granted they have to be coordinated on any reasonably complicated setup.
> > But there are simple cases where they don't necessarily need to be.
> > 
> > E.g. on a dumb "cp -ax / /nfs" backup it doesn't really matter "who"
> > does the backup as long as they have sufficient permissions, since the
> > files will all be explicitly chown'd as they're created.  And with krb5
> > it's simple enough to make that work with a single static mapping from a
> > client-side principal to root on the server.
> > 
> > And, again, that's something that works now with NFSv3.
> > 
> > --b.
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 
> 
> Another question is whether or not such an approach would be appreciated
> as part of 3530bis?

You want to add a discussion about AUTH_SYS support for 3530bis? I'd be
OK with that...

-- 
Trond Myklebust
Linux NFS client maintainer

NetApp
Trond.Myklebust@netapp.com
www.netapp.com

RE: NFSv4 behaviour on unknown users

[Spencer Shepler]

> -----Original Message-----
> From: linux-nfs-owner@vger.kernel.org [mailto:linux-nfs-
> owner@vger.kernel.org] On Behalf Of Trond Myklebust
> Sent: Thursday, December 02, 2010 3:18 PM
> To: Thomas Haynes
> Cc: J. Bruce Fields; Spelic; linux-nfs@vger.kernel.org
> Subject: Re: NFSv4 behaviour on unknown users
> 
> On Thu, 2010-12-02 at 17:10 -0600, Thomas Haynes wrote:
> > On Dec 1, 2010, at 10:29 AM, J. Bruce Fields wrote:
> >
> > > On Tue, Nov 30, 2010 at 10:10:02PM -0500, Trond Myklebust wrote:
> > >>
> > >> I think you need to take beepy's words in context here: as I
> > >> believe I mentioned previously, RFC3530 (and its predecessor
> > >> RFC3010) assumed everyone would be using principals for
> > >> authenticating, either through RPCSEC_GSS w/ krb5, or through the
> > >> SPKM/Lipkey mechanism. So sure was everyone of this, that AUTH_SYS
> > >> isn't even mentioned as a valid authentication mechanism, and so
> > >> nobody had to worry about the consequences of using it.
> > >
> > > I also wonder whether the value of a transparent upgrade from NFSv3
> > > got a little lost.
> > >
> > > To me that seems like the first requirement for version n+1 of
> > > anything--that we should be able to upgrade people to version n
> > > without their noticing.
> > >
> > > Maybe there are features that are necessarily incompatible, and that
> > > merit the downside, but the downside--losing the chance to get new
> > > features to every user automatically--seems significant to me.
> > >
> > >
> > > And, perhaps it's a disease, but I have gotten into the habit of
> > > thinking of the (krb5 principal)->(id, gid's) mapping as independent
> > > of the (NFSv4 user name)<->(uid) and (NFSv4 group name)<->(gid)
> mappings.
> > >
> > > Granted they have to be coordinated on any reasonably complicated
> setup.
> > > But there are simple cases where they don't necessarily need to be.
> > >
> > > E.g. on a dumb "cp -ax / /nfs" backup it doesn't really matter "who"
> > > does the backup as long as they have sufficient permissions, since
> > > the files will all be explicitly chown'd as they're created.  And
> > > with krb5 it's simple enough to make that work with a single static
> > > mapping from a client-side principal to root on the server.
> > >
> > > And, again, that's something that works now with NFSv3.
> > >
> > > --b.
> > > --
> > > To unsubscribe from this list: send the line "unsubscribe linux-nfs"
> > > in the body of a message to majordomo@vger.kernel.org More majordomo
> > > info at  http://vger.kernel.org/majordomo-info.html
> >
> >
> > Another question is whether or not such an approach would be
> > appreciated as part of 3530bis?
> 
> You want to add a discussion about AUTH_SYS support for 3530bis? I'd be OK
> with that...

What would the substance of such a discussion?

The NFSv4 RFCs do not preclude the use of a variety of RPC authentication types.
It asks that implementations treat the RPCSEC_GSS framework and the Kerberos
and lipkey types as mandatory to implement.

Given that the user of NFSv4 is not forced to use these or other authentication
methods, does the discussion reside in the interaction with these various
authentication types and their impact on the content of communicated attributes?

In any case, I would suggest a treatment of these issues be captured in a
separate I-D and ultimately a separate RFC to allow for expediency of
publication and application to NFSv4.0 and NFSv4.1.

Spencer

Re: NFSv4 behaviour on unknown users

['J. Bruce Fields']

On Thu, Dec 02, 2010 at 03:28:48PM -0800, Spencer Shepler wrote:
> 
> 
> > -----Original Message-----
> > From: linux-nfs-owner@vger.kernel.org [mailto:linux-nfs-
> > owner@vger.kernel.org] On Behalf Of Trond Myklebust
> > Sent: Thursday, December 02, 2010 3:18 PM
> > To: Thomas Haynes
> > Cc: J. Bruce Fields; Spelic; linux-nfs@vger.kernel.org
> > Subject: Re: NFSv4 behaviour on unknown users
> > 
> > On Thu, 2010-12-02 at 17:10 -0600, Thomas Haynes wrote:
> > > On Dec 1, 2010, at 10:29 AM, J. Bruce Fields wrote:
> > >
> > > > On Tue, Nov 30, 2010 at 10:10:02PM -0500, Trond Myklebust wrote:
> > > >>
> > > >> I think you need to take beepy's words in context here: as I
> > > >> believe I mentioned previously, RFC3530 (and its predecessor
> > > >> RFC3010) assumed everyone would be using principals for
> > > >> authenticating, either through RPCSEC_GSS w/ krb5, or through the
> > > >> SPKM/Lipkey mechanism. So sure was everyone of this, that AUTH_SYS
> > > >> isn't even mentioned as a valid authentication mechanism, and so
> > > >> nobody had to worry about the consequences of using it.
> > > >
> > > > I also wonder whether the value of a transparent upgrade from NFSv3
> > > > got a little lost.
> > > >
> > > > To me that seems like the first requirement for version n+1 of
> > > > anything--that we should be able to upgrade people to version n
> > > > without their noticing.
> > > >
> > > > Maybe there are features that are necessarily incompatible, and that
> > > > merit the downside, but the downside--losing the chance to get new
> > > > features to every user automatically--seems significant to me.
> > > >
> > > >
> > > > And, perhaps it's a disease, but I have gotten into the habit of
> > > > thinking of the (krb5 principal)->(id, gid's) mapping as independent
> > > > of the (NFSv4 user name)<->(uid) and (NFSv4 group name)<->(gid)
> > mappings.
> > > >
> > > > Granted they have to be coordinated on any reasonably complicated
> > setup.
> > > > But there are simple cases where they don't necessarily need to be.
> > > >
> > > > E.g. on a dumb "cp -ax / /nfs" backup it doesn't really matter "who"
> > > > does the backup as long as they have sufficient permissions, since
> > > > the files will all be explicitly chown'd as they're created.  And
> > > > with krb5 it's simple enough to make that work with a single static
> > > > mapping from a client-side principal to root on the server.
> > > >
> > > > And, again, that's something that works now with NFSv3.
> > > >
> > > > --b.
> > > > --
> > > > To unsubscribe from this list: send the line "unsubscribe linux-nfs"
> > > > in the body of a message to majordomo@vger.kernel.org More majordomo
> > > > info at  http://vger.kernel.org/majordomo-info.html
> > >
> > >
> > > Another question is whether or not such an approach would be
> > > appreciated as part of 3530bis?
> > 
> > You want to add a discussion about AUTH_SYS support for 3530bis? I'd be OK
> > with that...
> 
> What would the substance of such a discussion?
> 
> The NFSv4 RFCs do not preclude the use of a variety of RPC authentication types.
> It asks that implementations treat the RPCSEC_GSS framework and the Kerberos
> and lipkey types as mandatory to implement.
> 
> Given that the user of NFSv4 is not forced to use these or other authentication
> methods, does the discussion reside in the interaction with these various
> authentication types and their impact on the content of communicated attributes?
> 
> In any case, I would suggest a treatment of these issues be captured in a
> separate I-D and ultimately a separate RFC to allow for expediency of
> publication and application to NFSv4.0 and NFSv4.1.

The v3->v4 upgrade would be dead-simple if the default (without *any*
idmapping configuration) was to send and receive purely numeric id's.

A client that attempts that with a server that has normal NFSv4
name-mapping set up will see "nobody" on any "ls" and get BADOWNER on
any attempt to set anything, but that's more or less the typical
experience right now, and as a default if anything numeric id's seems
safer than guessing a domain and assuming local account names map into
it.

And as soon as some form of idmapping is set up (even if it's just
setting a default domain, effectively just a declaration that any local
account <user> is also an nfsv4 user <user>@<domain>), things work
normally.

I don't see any of this as a violation of the spec, which allows use of
numeric id's in the absence of a "valid translation" for a user or
group.

And the mere existance of a local account with a certain name doesn't
imply the existance of a valid translation into any nfsv4 namespace.

So if that makes sense, then I don't think any change to rfc 3530
section 5.8 is required beyond possibly some clarification or change in
emphasis.

(I see AUTH_SYS as a different issue.  It's unfortunately true that
AUTH_SYS has effectively turned out to be required-to-implement even if
it wasn't meant to be, so maybe the spec's out of line with reality
there; but I haven't heard of that causing any practical
problems--whereas "why does ls show all users as nobody after an upgrade
to NFSv4" is a FAQ.)

--b.

Re: NFSv4 behaviour on unknown users

[Thomas Haynes]

On Dec 7, 2010, at 4:15 PM, J. Bruce Fields wrote:

> 
> (I see AUTH_SYS as a different issue.  It's unfortunately true that
> AUTH_SYS has effectively turned out to be required-to-implement even if
> it wasn't meant to be, so maybe the spec's out of line with reality
> there; but I haven't heard of that causing any practical
> problems--whereas "why does ls show all users as nobody after an upgrade
> to NFSv4" is a FAQ.)
> 
> --b.



If everyone were to adopt this approach to solve the FAQ, then wouldn't we
want it to be specified to make sure that interoperability was maximized?

Re: NFSv4 behaviour on unknown users

[J. Bruce Fields]

On Fri, Dec 10, 2010 at 11:00:08AM -0800, Thomas Haynes wrote:
> 
> On Dec 7, 2010, at 4:15 PM, J. Bruce Fields wrote:
> 
> > 
> > (I see AUTH_SYS as a different issue.  It's unfortunately true that
> > AUTH_SYS has effectively turned out to be required-to-implement even if
> > it wasn't meant to be, so maybe the spec's out of line with reality
> > there; but I haven't heard of that causing any practical
> > problems--whereas "why does ls show all users as nobody after an upgrade
> > to NFSv4" is a FAQ.)
> 
> If everyone were to adopt this approach to solve the FAQ, then wouldn't we
> want it to be specified to make sure that interoperability was maximized?

Sorry for the confusion--that last paragraph was just about AUTH_SYS,
not about user/group-naming.

Sure, I'd be happy to propose changes to the user/group-naming (which is
all in section 5.8 of 3530, I think, or is there some scattered
elsewhere?)

--b.

RE: NFSv4 behaviour on unknown users

[Daniel.Muntz]

Looks like it's time for my annual numeric uid rant...

IMHO this was the silliest decision in the v4 spec, and a frequent hindrance to users wanting to move from v3.  Once again, I'm going to suggest that the v4.x series officially support numeric uid/gid strings as first-class user identifiers, rather than trying to force "name@domain" on systems that do not need this functionality, and are worse off for having to support it.  The fact that every OS needs different configuration to get it working just adds to the insanity.  Supply something that works (numeric id strings) as the default, but allow the name@domain "enhancement" for those who want it.  Then, everything just works, people seamlessly migrate to v4.x, and world peace is achieved.  There could even be an option to disable numeric id string support for those vehemently opposed to its existence, but at least in this case sysadmins have to go out of their way to make their system return nobody/nogroup for all users, rather than being the default behavior.

  -Dan

-----Original Message-----
From: linux-nfs-owner@vger.kernel.org [mailto:linux-nfs-owner@vger.kernel.org] On Behalf Of Trond Myklebust
Sent: Monday, November 29, 2010 10:23 AM
To: Spelic
Cc: linux-nfs@vger.kernel.org
Subject: Re: NFSv4 behaviour on unknown users

On Mon, 2010-11-29 at 19:12 +0100, Spelic wrote:
> Hello all
> we recently moved to nfsv4 from v3.
> 
> I'm currently using idmapd and not kerberos.
> 
> I noticed that now, with idmapd (and with idmapd is the only way I know 
> for configuring nfsv4 for now), users that are not known at server side 
> are squashed to nobody / nogroup  (65534 / 65534).
> And a chown by root from the client fails if the user is not known at 
> server side.
> 
> That's a problem... now we need ldap everywhere...
> 
> We were often using NFS for exporting some diskspace to machines on an 
> as-needed basis,
> so this new behaviour complicates the things greatly for us :-/
> It's almost easier to setup iSCSI targets now :-((
> 
> Is there a way to have nfsv4 with the behaviour of users of nfsv3, that 
> is, using numeric IDs instead of the names, like: "nfsserver, don't care 
> if you don't know the user, just give me the numeric ID for the file..."

No. That is not allowed by the spec.

Trond
-- 
Trond Myklebust
Linux NFS client maintainer

NetApp
Trond.Myklebust@netapp.com
www.netapp.com

--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: NFSv4 behaviour on unknown users

[Spencer Shepler]

Dan,

A change to the NFSv4.0 and NFSv4.1 RFCs is unnecessary.
What you suggest can be implemented today and still adhere
to the RFC text.  From RFC3530 (section 4.8) and RFC5661 (section 5.9)
the following text is quoted:

"  In the case where there is no translation available to the client or
   server, the attribute value will be constructed without the "@".
   Therefore, the absence of the @ from the owner or owner_group
   attribute signifies that no translation was available at the sender
   and that the receiver of the attribute should not use that string as
   a basis for translation into its own internal format.  Even though
   the attribute value cannot be translated, it may still be useful.  In
   the case of a client, the attribute string may be used for local
   display of ownership.

   To provide a greater degree of compatibility with NFSv3, which
   identified users and groups by 32-bit unsigned user identifiers and
   group identifiers, owner and group strings that consist of decimal
   numeric values with no leading zeros can be given a special
   interpretation by clients and servers that choose to provide such
   support.  The receiver may treat such a user or group string as
   representing the same user as would be represented by an NFSv3 uid or
   gid having the corresponding numeric value.  A server is not
   obligated to accept such a string, but may return an NFS4ERR_BADOWNER
   instead.  To avoid this mechanism being used to subvert user and
   group translation, so that a client might pass all of the owners and
   groups in numeric form, a server SHOULD return an NFS4ERR_BADOWNER
   error when there is a valid translation for the user or owner
   designated in this way.  In that case, the client must use the
   appropriate name@domain string and not the special form for
   compatibility."


I read this that if the implementation or administrator chooses
to op-out of the user@domain mapping, it may do so and the client
and server have a method available to them to communicate traditiona
uid/gid.

So, all that is needed now it seems is some code to provide the
option to the admin or as you suggest, change the default.

Spencer


> -----Original Message-----
> From: linux-nfs-owner@vger.kernel.org [mailto:linux-nfs-
> owner@vger.kernel.org] On Behalf Of Daniel.Muntz@emc.com
> Sent: Monday, November 29, 2010 2:09 PM
> To: Trond.Myklebust@netapp.com; spelic@shiftmail.org
> Cc: linux-nfs@vger.kernel.org
> Subject: RE: NFSv4 behaviour on unknown users
> 
> Looks like it's time for my annual numeric uid rant...
> 
> IMHO this was the silliest decision in the v4 spec, and a frequent
> hindrance to users wanting to move from v3.  Once again, I'm going to
> suggest that the v4.x series officially support numeric uid/gid strings as
> first-class user identifiers, rather than trying to force "name@domain" on
> systems that do not need this functionality, and are worse off for having
> to support it.  The fact that every OS needs different configuration to
> get it working just adds to the insanity.  Supply something that works
> (numeric id strings) as the default, but allow the name@domain
> "enhancement" for those who want it.  Then, everything just works, people
> seamlessly migrate to v4.x, and world peace is achieved.  There could even
> be an option to disable numeric id string support for those vehemently
> opposed to its existence, but at least in this case sysadmins have to go
> out of their way to make their system return nobody/nogroup for all users,
> rather than being the default behavior.
> 
>   -Dan
> 
> -----Original Message-----
> From: linux-nfs-owner@vger.kernel.org [mailto:linux-nfs-
> owner@vger.kernel.org] On Behalf Of Trond Myklebust
> Sent: Monday, November 29, 2010 10:23 AM
> To: Spelic
> Cc: linux-nfs@vger.kernel.org
> Subject: Re: NFSv4 behaviour on unknown users
> 
> On Mon, 2010-11-29 at 19:12 +0100, Spelic wrote:
> > Hello all
> > we recently moved to nfsv4 from v3.
> >
> > I'm currently using idmapd and not kerberos.
> >
> > I noticed that now, with idmapd (and with idmapd is the only way I
> > know for configuring nfsv4 for now), users that are not known at
> > server side are squashed to nobody / nogroup  (65534 / 65534).
> > And a chown by root from the client fails if the user is not known at
> > server side.
> >
> > That's a problem... now we need ldap everywhere...
> >
> > We were often using NFS for exporting some diskspace to machines on an
> > as-needed basis, so this new behaviour complicates the things greatly
> > for us :-/ It's almost easier to setup iSCSI targets now :-((
> >
> > Is there a way to have nfsv4 with the behaviour of users of nfsv3,
> > that is, using numeric IDs instead of the names, like: "nfsserver,
> > don't care if you don't know the user, just give me the numeric ID for
> the file..."
> 
> No. That is not allowed by the spec.
> 
> Trond
> --
> Trond Myklebust
> Linux NFS client maintainer
> 
> NetApp
> Trond.Myklebust@netapp.com
> www.netapp.com
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
> the body of a message to majordomo@vger.kernel.org More majordomo info at
> http://vger.kernel.org/majordomo-info.html
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
> the body of a message to majordomo@vger.kernel.org More majordomo info at
> http://vger.kernel.org/majordomo-info.html

RE: NFSv4 behaviour on unknown users

[Trond Myklebust]

On Mon, 2010-11-29 at 14:57 -0800, Spencer Shepler wrote:
> Dan,
> 
> A change to the NFSv4.0 and NFSv4.1 RFCs is unnecessary.
> What you suggest can be implemented today and still adhere
> to the RFC text.  From RFC3530 (section 4.8) and RFC5661 (section 5.9)
> the following text is quoted:
> 
> "  In the case where there is no translation available to the client or
>    server, the attribute value will be constructed without the "@".
>    Therefore, the absence of the @ from the owner or owner_group
>    attribute signifies that no translation was available at the sender
>    and that the receiver of the attribute should not use that string as
>    a basis for translation into its own internal format.  Even though
>    the attribute value cannot be translated, it may still be useful.  In
>    the case of a client, the attribute string may be used for local
>    display of ownership.
> 
>    To provide a greater degree of compatibility with NFSv3, which
>    identified users and groups by 32-bit unsigned user identifiers and
>    group identifiers, owner and group strings that consist of decimal
>    numeric values with no leading zeros can be given a special
>    interpretation by clients and servers that choose to provide such
>    support.  The receiver may treat such a user or group string as
>    representing the same user as would be represented by an NFSv3 uid or
>    gid having the corresponding numeric value.  A server is not
>    obligated to accept such a string, but may return an NFS4ERR_BADOWNER
>    instead.  To avoid this mechanism being used to subvert user and
>    group translation, so that a client might pass all of the owners and
>    groups in numeric form, a server SHOULD return an NFS4ERR_BADOWNER
>    error when there is a valid translation for the user or owner
>    designated in this way.  In that case, the client must use the
>    appropriate name@domain string and not the special form for
>    compatibility."
> 
> 
> I read this that if the implementation or administrator chooses
> to op-out of the user@domain mapping, it may do so and the client
> and server have a method available to them to communicate traditiona
> uid/gid.
> 
> So, all that is needed now it seems is some code to provide the
> option to the admin or as you suggest, change the default.
> 
> Spencer

It is way too late to change the default. All known existing NFSv4
servers would spit at you because they have been coded to match the
above normative "SHOULD".

Without that option, you will also need a mechanism to allow the client
and server to agree on a convention. Otherwise, admins have to go in and
manually set the correct site default on all their clients and servers.

Trond


> > -----Original Message-----
> > From: linux-nfs-owner@vger.kernel.org [mailto:linux-nfs-
> > owner@vger.kernel.org] On Behalf Of Daniel.Muntz@emc.com
> > Sent: Monday, November 29, 2010 2:09 PM
> > To: Trond.Myklebust@netapp.com; spelic@shiftmail.org
> > Cc: linux-nfs@vger.kernel.org
> > Subject: RE: NFSv4 behaviour on unknown users
> > 
> > Looks like it's time for my annual numeric uid rant...
> > 
> > IMHO this was the silliest decision in the v4 spec, and a frequent
> > hindrance to users wanting to move from v3.  Once again, I'm going to
> > suggest that the v4.x series officially support numeric uid/gid strings as
> > first-class user identifiers, rather than trying to force "name@domain" on
> > systems that do not need this functionality, and are worse off for having
> > to support it.  The fact that every OS needs different configuration to
> > get it working just adds to the insanity.  Supply something that works
> > (numeric id strings) as the default, but allow the name@domain
> > "enhancement" for those who want it.  Then, everything just works, people
> > seamlessly migrate to v4.x, and world peace is achieved.  There could even
> > be an option to disable numeric id string support for those vehemently
> > opposed to its existence, but at least in this case sysadmins have to go
> > out of their way to make their system return nobody/nogroup for all users,
> > rather than being the default behavior.
> > 
> >   -Dan
> > 
> > -----Original Message-----
> > From: linux-nfs-owner@vger.kernel.org [mailto:linux-nfs-
> > owner@vger.kernel.org] On Behalf Of Trond Myklebust
> > Sent: Monday, November 29, 2010 10:23 AM
> > To: Spelic
> > Cc: linux-nfs@vger.kernel.org
> > Subject: Re: NFSv4 behaviour on unknown users
> > 
> > On Mon, 2010-11-29 at 19:12 +0100, Spelic wrote:
> > > Hello all
> > > we recently moved to nfsv4 from v3.
> > >
> > > I'm currently using idmapd and not kerberos.
> > >
> > > I noticed that now, with idmapd (and with idmapd is the only way I
> > > know for configuring nfsv4 for now), users that are not known at
> > > server side are squashed to nobody / nogroup  (65534 / 65534).
> > > And a chown by root from the client fails if the user is not known at
> > > server side.
> > >
> > > That's a problem... now we need ldap everywhere...
> > >
> > > We were often using NFS for exporting some diskspace to machines on an
> > > as-needed basis, so this new behaviour complicates the things greatly
> > > for us :-/ It's almost easier to setup iSCSI targets now :-((
> > >
> > > Is there a way to have nfsv4 with the behaviour of users of nfsv3,
> > > that is, using numeric IDs instead of the names, like: "nfsserver,
> > > don't care if you don't know the user, just give me the numeric ID for
> > the file..."
> > 
> > No. That is not allowed by the spec.
> > 
> > Trond
> > --
> > Trond Myklebust
> > Linux NFS client maintainer
> > 
> > NetApp
> > Trond.Myklebust@netapp.com
> > www.netapp.com
> > 
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
> > the body of a message to majordomo@vger.kernel.org More majordomo info at
> > http://vger.kernel.org/majordomo-info.html
> > 
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
> > the body of a message to majordomo@vger.kernel.org More majordomo info at
> > http://vger.kernel.org/majordomo-info.html
> 

-- 
Trond Myklebust
Linux NFS client maintainer

NetApp
Trond.Myklebust@netapp.com
www.netapp.com

RE: NFSv4 behaviour on unknown users

[Spencer Shepler]

> -----Original Message-----
> From: Trond Myklebust [mailto:Trond.Myklebust@netapp.com]
> Sent: Monday, November 29, 2010 3:16 PM
> To: Spencer Shepler
> Cc: Daniel.Muntz@emc.com; spelic@shiftmail.org; linux-nfs@vger.kernel.org
> Subject: RE: NFSv4 behaviour on unknown users
> 
> On Mon, 2010-11-29 at 14:57 -0800, Spencer Shepler wrote:
> > Dan,
> >
> > A change to the NFSv4.0 and NFSv4.1 RFCs is unnecessary.
> > What you suggest can be implemented today and still adhere to the RFC
> > text.  From RFC3530 (section 4.8) and RFC5661 (section 5.9) the
> > following text is quoted:
> >
> > "  In the case where there is no translation available to the client or
> >    server, the attribute value will be constructed without the "@".
> >    Therefore, the absence of the @ from the owner or owner_group
> >    attribute signifies that no translation was available at the sender
> >    and that the receiver of the attribute should not use that string as
> >    a basis for translation into its own internal format.  Even though
> >    the attribute value cannot be translated, it may still be useful.  In
> >    the case of a client, the attribute string may be used for local
> >    display of ownership.
> >
> >    To provide a greater degree of compatibility with NFSv3, which
> >    identified users and groups by 32-bit unsigned user identifiers and
> >    group identifiers, owner and group strings that consist of decimal
> >    numeric values with no leading zeros can be given a special
> >    interpretation by clients and servers that choose to provide such
> >    support.  The receiver may treat such a user or group string as
> >    representing the same user as would be represented by an NFSv3 uid or
> >    gid having the corresponding numeric value.  A server is not
> >    obligated to accept such a string, but may return an NFS4ERR_BADOWNER
> >    instead.  To avoid this mechanism being used to subvert user and
> >    group translation, so that a client might pass all of the owners and
> >    groups in numeric form, a server SHOULD return an NFS4ERR_BADOWNER
> >    error when there is a valid translation for the user or owner
> >    designated in this way.  In that case, the client must use the
> >    appropriate name@domain string and not the special form for
> >    compatibility."
> >
> >
> > I read this that if the implementation or administrator chooses to
> > op-out of the user@domain mapping, it may do so and the client and
> > server have a method available to them to communicate traditiona
> > uid/gid.
> >
> > So, all that is needed now it seems is some code to provide the option
> > to the admin or as you suggest, change the default.
> >
> > Spencer
> 
> It is way too late to change the default. All known existing NFSv4 servers
> would spit at you because they have been coded to match the above
> normative "SHOULD".

The intent of my email was to state that a change of the RFCs was
not required to build a solution that addresses the deployment
described.

It may be that the servers in question can be changed as easily
as the clients and therefore a solution is quite possible.

So, it is possible.  Now the question of probable is in play.

> 
> Without that option, you will also need a mechanism to allow the client
> and server to agree on a convention. Otherwise, admins have to go in and
> manually set the correct site default on all their clients and servers.

IIRC, the Solaris implementation will encode the uid/gid as
a simple "stringified" uid/gid without the "@".  Seems simple
enough and quite portable.  If the linux implementation were
to choose that as the default, others will follow.

Spencer

> 
> Trond
> 
> 
> > > -----Original Message-----
> > > From: linux-nfs-owner@vger.kernel.org [mailto:linux-nfs-
> > > owner@vger.kernel.org] On Behalf Of Daniel.Muntz@emc.com
> > > Sent: Monday, November 29, 2010 2:09 PM
> > > To: Trond.Myklebust@netapp.com; spelic@shiftmail.org
> > > Cc: linux-nfs@vger.kernel.org
> > > Subject: RE: NFSv4 behaviour on unknown users
> > >
> > > Looks like it's time for my annual numeric uid rant...
> > >
> > > IMHO this was the silliest decision in the v4 spec, and a frequent
> > > hindrance to users wanting to move from v3.  Once again, I'm going
> > > to suggest that the v4.x series officially support numeric uid/gid
> > > strings as first-class user identifiers, rather than trying to force
> > > "name@domain" on systems that do not need this functionality, and
> > > are worse off for having to support it.  The fact that every OS
> > > needs different configuration to get it working just adds to the
> > > insanity.  Supply something that works (numeric id strings) as the
> > > default, but allow the name@domain "enhancement" for those who want
> > > it.  Then, everything just works, people seamlessly migrate to v4.x,
> > > and world peace is achieved.  There could even be an option to
> > > disable numeric id string support for those vehemently opposed to
> > > its existence, but at least in this case sysadmins have to go out of
> > > their way to make their system return nobody/nogroup for all users,
> rather than being the default behavior.
> > >
> > >   -Dan
> > >
> > > -----Original Message-----
> > > From: linux-nfs-owner@vger.kernel.org [mailto:linux-nfs-
> > > owner@vger.kernel.org] On Behalf Of Trond Myklebust
> > > Sent: Monday, November 29, 2010 10:23 AM
> > > To: Spelic
> > > Cc: linux-nfs@vger.kernel.org
> > > Subject: Re: NFSv4 behaviour on unknown users
> > >
> > > On Mon, 2010-11-29 at 19:12 +0100, Spelic wrote:
> > > > Hello all
> > > > we recently moved to nfsv4 from v3.
> > > >
> > > > I'm currently using idmapd and not kerberos.
> > > >
> > > > I noticed that now, with idmapd (and with idmapd is the only way I
> > > > know for configuring nfsv4 for now), users that are not known at
> > > > server side are squashed to nobody / nogroup  (65534 / 65534).
> > > > And a chown by root from the client fails if the user is not known
> > > > at server side.
> > > >
> > > > That's a problem... now we need ldap everywhere...
> > > >
> > > > We were often using NFS for exporting some diskspace to machines
> > > > on an as-needed basis, so this new behaviour complicates the
> > > > things greatly for us :-/ It's almost easier to setup iSCSI
> > > > targets now :-((
> > > >
> > > > Is there a way to have nfsv4 with the behaviour of users of nfsv3,
> > > > that is, using numeric IDs instead of the names, like: "nfsserver,
> > > > don't care if you don't know the user, just give me the numeric ID
> > > > for
> > > the file..."
> > >
> > > No. That is not allowed by the spec.
> > >
> > > Trond
> > > --
> > > Trond Myklebust
> > > Linux NFS client maintainer
> > >
> > > NetApp
> > > Trond.Myklebust@netapp.com
> > > www.netapp.com
> > >
> > > --
> > > To unsubscribe from this list: send the line "unsubscribe linux-nfs"
> > > in the body of a message to majordomo@vger.kernel.org More majordomo
> > > info at http://vger.kernel.org/majordomo-info.html
> > >
> > > --
> > > To unsubscribe from this list: send the line "unsubscribe linux-nfs"
> > > in the body of a message to majordomo@vger.kernel.org More majordomo
> > > info at http://vger.kernel.org/majordomo-info.html
> >
> 
> --
> Trond Myklebust
> Linux NFS client maintainer
> 
> NetApp
> Trond.Myklebust@netapp.com
> www.netapp.com

RE: NFSv4 behaviour on unknown users

[Trond Myklebust]

On Mon, 2010-11-29 at 18:16 -0500, Trond Myklebust wrote:
> On Mon, 2010-11-29 at 14:57 -0800, Spencer Shepler wrote:
> > Dan,
> > 
> > A change to the NFSv4.0 and NFSv4.1 RFCs is unnecessary.
> > What you suggest can be implemented today and still adhere
> > to the RFC text.  From RFC3530 (section 4.8) and RFC5661 (section 5.9)
> > the following text is quoted:
> > 
> > "  In the case where there is no translation available to the client or
> >    server, the attribute value will be constructed without the "@".
> >    Therefore, the absence of the @ from the owner or owner_group
> >    attribute signifies that no translation was available at the sender
> >    and that the receiver of the attribute should not use that string as
> >    a basis for translation into its own internal format.  Even though
> >    the attribute value cannot be translated, it may still be useful.  In
> >    the case of a client, the attribute string may be used for local
> >    display of ownership.
> > 
> >    To provide a greater degree of compatibility with NFSv3, which
> >    identified users and groups by 32-bit unsigned user identifiers and
> >    group identifiers, owner and group strings that consist of decimal
> >    numeric values with no leading zeros can be given a special
> >    interpretation by clients and servers that choose to provide such
> >    support.  The receiver may treat such a user or group string as
> >    representing the same user as would be represented by an NFSv3 uid or
> >    gid having the corresponding numeric value.  A server is not
> >    obligated to accept such a string, but may return an NFS4ERR_BADOWNER
> >    instead.  To avoid this mechanism being used to subvert user and
> >    group translation, so that a client might pass all of the owners and
> >    groups in numeric form, a server SHOULD return an NFS4ERR_BADOWNER
> >    error when there is a valid translation for the user or owner
> >    designated in this way.  In that case, the client must use the
> >    appropriate name@domain string and not the special form for
> >    compatibility."
> > 
> > 
> > I read this that if the implementation or administrator chooses
> > to op-out of the user@domain mapping, it may do so and the client
> > and server have a method available to them to communicate traditiona
> > uid/gid.
> > 
> > So, all that is needed now it seems is some code to provide the
> > option to the admin or as you suggest, change the default.
> > 
> > Spencer
> 
> It is way too late to change the default. All known existing NFSv4
> servers would spit at you because they have been coded to match the
> above normative "SHOULD".
> 
> Without that option, you will also need a mechanism to allow the client
> and server to agree on a convention. Otherwise, admins have to go in and
> manually set the correct site default on all their clients and servers.

The other problem is that when you use the naked uid or gid you are
losing information about which domain the user belongs to.

While that may be fine when you are authenticating using the AUTH_SYS
security flavour, it is just plain wrong when you are authenticating
using RPCSEC_GSS principals (which is what the NFSv4 spec assumes that
you will use).

-- 
Trond Myklebust
Linux NFS client maintainer

NetApp
Trond.Myklebust@netapp.com
www.netapp.com

RE: NFSv4 behaviour on unknown users

[Spencer Shepler]

> -----Original Message-----
> From: Trond Myklebust [mailto:Trond.Myklebust@netapp.com]
> Sent: Monday, November 29, 2010 3:26 PM
> To: Spencer Shepler
> Cc: Daniel.Muntz@emc.com; spelic@shiftmail.org; linux-nfs@vger.kernel.org
> Subject: RE: NFSv4 behaviour on unknown users
> 
> On Mon, 2010-11-29 at 18:16 -0500, Trond Myklebust wrote:
> > On Mon, 2010-11-29 at 14:57 -0800, Spencer Shepler wrote:
> > > Dan,
> > >
> > > A change to the NFSv4.0 and NFSv4.1 RFCs is unnecessary.
> > > What you suggest can be implemented today and still adhere to the
> > > RFC text.  From RFC3530 (section 4.8) and RFC5661 (section 5.9) the
> > > following text is quoted:
> > >
> > > "  In the case where there is no translation available to the client
> or
> > >    server, the attribute value will be constructed without the "@".
> > >    Therefore, the absence of the @ from the owner or owner_group
> > >    attribute signifies that no translation was available at the sender
> > >    and that the receiver of the attribute should not use that string
> as
> > >    a basis for translation into its own internal format.  Even though
> > >    the attribute value cannot be translated, it may still be useful.
> In
> > >    the case of a client, the attribute string may be used for local
> > >    display of ownership.
> > >
> > >    To provide a greater degree of compatibility with NFSv3, which
> > >    identified users and groups by 32-bit unsigned user identifiers and
> > >    group identifiers, owner and group strings that consist of decimal
> > >    numeric values with no leading zeros can be given a special
> > >    interpretation by clients and servers that choose to provide such
> > >    support.  The receiver may treat such a user or group string as
> > >    representing the same user as would be represented by an NFSv3 uid
> or
> > >    gid having the corresponding numeric value.  A server is not
> > >    obligated to accept such a string, but may return an
> NFS4ERR_BADOWNER
> > >    instead.  To avoid this mechanism being used to subvert user and
> > >    group translation, so that a client might pass all of the owners
> and
> > >    groups in numeric form, a server SHOULD return an NFS4ERR_BADOWNER
> > >    error when there is a valid translation for the user or owner
> > >    designated in this way.  In that case, the client must use the
> > >    appropriate name@domain string and not the special form for
> > >    compatibility."
> > >
> > >
> > > I read this that if the implementation or administrator chooses to
> > > op-out of the user@domain mapping, it may do so and the client and
> > > server have a method available to them to communicate traditiona
> > > uid/gid.
> > >
> > > So, all that is needed now it seems is some code to provide the
> > > option to the admin or as you suggest, change the default.
> > >
> > > Spencer
> >
> > It is way too late to change the default. All known existing NFSv4
> > servers would spit at you because they have been coded to match the
> > above normative "SHOULD".
> >
> > Without that option, you will also need a mechanism to allow the
> > client and server to agree on a convention. Otherwise, admins have to
> > go in and manually set the correct site default on all their clients and
> servers.
> 
> The other problem is that when you use the naked uid or gid you are losing
> information about which domain the user belongs to.
> 
> While that may be fine when you are authenticating using the AUTH_SYS
> security flavour, it is just plain wrong when you are authenticating using
> RPCSEC_GSS principals (which is what the NFSv4 spec assumes that you will
> use).

Then the administrator will not use that option.

The use case that was presented did not use Kerberos (at least in my quick reading).

I agree that users that use Kerberos will be unhappy and that they should
use something that maps more in align with their Kerberos realms but that
is not the pain point under discussion.  A variation of the id mapping work
under discussion by Andy would/could address Kerberos and other deployment
scenarios.  But for the original "works for NFSv3 and doesn't for NFSv4" crowd
something simple will suffice and they will be happy and stop bitching
about this and move onto the next thing that pisses them off. :-)

Spencer

> 
> --
> Trond Myklebust
> Linux NFS client maintainer
> 
> NetApp
> Trond.Myklebust@netapp.com
> www.netapp.com

RE: NFSv4 behaviour on unknown users

[Trond Myklebust]

On Mon, 2010-11-29 at 15:30 -0800, Spencer Shepler wrote:
> 
> > -----Original Message-----
> > From: Trond Myklebust [mailto:Trond.Myklebust@netapp.com]
> > Sent: Monday, November 29, 2010 3:26 PM
> > To: Spencer Shepler
> > Cc: Daniel.Muntz@emc.com; spelic@shiftmail.org; linux-nfs@vger.kernel.org
> > Subject: RE: NFSv4 behaviour on unknown users
> > 
> > On Mon, 2010-11-29 at 18:16 -0500, Trond Myklebust wrote:
> > > On Mon, 2010-11-29 at 14:57 -0800, Spencer Shepler wrote:
> > > > Dan,
> > > >
> > > > A change to the NFSv4.0 and NFSv4.1 RFCs is unnecessary.
> > > > What you suggest can be implemented today and still adhere to the
> > > > RFC text.  From RFC3530 (section 4.8) and RFC5661 (section 5.9) the
> > > > following text is quoted:
> > > >
> > > > "  In the case where there is no translation available to the client
> > or
> > > >    server, the attribute value will be constructed without the "@".
> > > >    Therefore, the absence of the @ from the owner or owner_group
> > > >    attribute signifies that no translation was available at the sender
> > > >    and that the receiver of the attribute should not use that string
> > as
> > > >    a basis for translation into its own internal format.  Even though
> > > >    the attribute value cannot be translated, it may still be useful.
> > In
> > > >    the case of a client, the attribute string may be used for local
> > > >    display of ownership.
> > > >
> > > >    To provide a greater degree of compatibility with NFSv3, which
> > > >    identified users and groups by 32-bit unsigned user identifiers and
> > > >    group identifiers, owner and group strings that consist of decimal
> > > >    numeric values with no leading zeros can be given a special
> > > >    interpretation by clients and servers that choose to provide such
> > > >    support.  The receiver may treat such a user or group string as
> > > >    representing the same user as would be represented by an NFSv3 uid
> > or
> > > >    gid having the corresponding numeric value.  A server is not
> > > >    obligated to accept such a string, but may return an
> > NFS4ERR_BADOWNER
> > > >    instead.  To avoid this mechanism being used to subvert user and
> > > >    group translation, so that a client might pass all of the owners
> > and
> > > >    groups in numeric form, a server SHOULD return an NFS4ERR_BADOWNER
> > > >    error when there is a valid translation for the user or owner
> > > >    designated in this way.  In that case, the client must use the
> > > >    appropriate name@domain string and not the special form for
> > > >    compatibility."
> > > >
> > > >
> > > > I read this that if the implementation or administrator chooses to
> > > > op-out of the user@domain mapping, it may do so and the client and
> > > > server have a method available to them to communicate traditiona
> > > > uid/gid.
> > > >
> > > > So, all that is needed now it seems is some code to provide the
> > > > option to the admin or as you suggest, change the default.
> > > >
> > > > Spencer
> > >
> > > It is way too late to change the default. All known existing NFSv4
> > > servers would spit at you because they have been coded to match the
> > > above normative "SHOULD".
> > >
> > > Without that option, you will also need a mechanism to allow the
> > > client and server to agree on a convention. Otherwise, admins have to
> > > go in and manually set the correct site default on all their clients and
> > servers.
> > 
> > The other problem is that when you use the naked uid or gid you are losing
> > information about which domain the user belongs to.
> > 
> > While that may be fine when you are authenticating using the AUTH_SYS
> > security flavour, it is just plain wrong when you are authenticating using
> > RPCSEC_GSS principals (which is what the NFSv4 spec assumes that you will
> > use).
> 
> Then the administrator will not use that option.
> 
> The use case that was presented did not use Kerberos (at least in my quick reading).
> 
> I agree that users that use Kerberos will be unhappy and that they should
> use something that maps more in align with their Kerberos realms but that
> is not the pain point under discussion.  A variation of the id mapping work
> under discussion by Andy would/could address Kerberos and other deployment
> scenarios.  But for the original "works for NFSv3 and doesn't for NFSv4" crowd
> something simple will suffice and they will be happy and stop bitching
> about this and move onto the next thing that pisses them off. :-)

It would not be backwards compatible: the linux server will currently
reject any uid/gid usage by the client.

That said, I can imagine that for 'sec=sys', we might be able to change
the client to use the uid/gid format by default, and then change back to
doing name@domain upon receiving the first NFS4ERR_BADOWNER error from
the server.
It the server changes to match this, then that might suffice solve the
current problem that we have with doing nfsroot on NFSv4...

Trond
-- 
Trond Myklebust
Linux NFS client maintainer

NetApp
Trond.Myklebust@netapp.com
www.netapp.com

RE: NFSv4 behaviour on unknown users

[Spencer Shepler]

> -----Original Message-----
> From: Trond Myklebust [mailto:Trond.Myklebust@netapp.com]

<trim>

> > > servers.
> > >
> > > The other problem is that when you use the naked uid or gid you are
> > > losing information about which domain the user belongs to.
> > >
> > > While that may be fine when you are authenticating using the
> > > AUTH_SYS security flavour, it is just plain wrong when you are
> > > authenticating using RPCSEC_GSS principals (which is what the NFSv4
> > > spec assumes that you will use).
> >
> > Then the administrator will not use that option.
> >
> > The use case that was presented did not use Kerberos (at least in my
> quick reading).
> >
> > I agree that users that use Kerberos will be unhappy and that they
> > should use something that maps more in align with their Kerberos
> > realms but that is not the pain point under discussion.  A variation
> > of the id mapping work under discussion by Andy would/could address
> > Kerberos and other deployment scenarios.  But for the original "works
> > for NFSv3 and doesn't for NFSv4" crowd something simple will suffice
> > and they will be happy and stop bitching about this and move onto the
> > next thing that pisses them off. :-)
> 
> It would not be backwards compatible: the linux server will currently
> reject any uid/gid usage by the client.
> 
> That said, I can imagine that for 'sec=sys', we might be able to change
> the client to use the uid/gid format by default, and then change back to
> doing name@domain upon receiving the first NFS4ERR_BADOWNER error from the
> server.
> It the server changes to match this, then that might suffice solve the
> current problem that we have with doing nfsroot on NFSv4...

IMO: I wouldn't worry about the mixed scenarios to start with.
Provide the option on the client and server to use the straight-up
uid/gid to string mappings and this will satisfy these simple
deployments that are or will have trouble.  In the mixed environments,
there is more work but at least there is something available for
admins to get started with.

Spencer


> 
> Trond
> --
> Trond Myklebust
> Linux NFS client maintainer
> 
> NetApp
> Trond.Myklebust@netapp.com
> www.netapp.com

Re: NFSv4 behaviour on unknown users

[Spelic]

On 11/30/2010 01:02 AM, Spencer Shepler wrote:
>> It would not be backwards compatible: the linux server will currently
>> reject any uid/gid usage by the client.
>>
>> That said, I can imagine that for 'sec=sys', we might be able to change
>> the client to use the uid/gid format by default, and then change back to
>> doing name@domain upon receiving the first NFS4ERR_BADOWNER error from the
>> server.
>> It the server changes to match this, then that might suffice solve the
>> current problem that we have with doing nfsroot on NFSv4...
>>      
> IMO: I wouldn't worry about the mixed scenarios to start with.
> Provide the option on the client and server to use the straight-up
> uid/gid to string mappings and this will satisfy these simple
> deployments that are or will have trouble.
>    

+1 for this.  Changing mapping on the fly at the first NFS4ERR_BADOWNER 
received does not look very reliable to me: is scarcely controllable by 
the sysadmin and is gonna make the thing a headache to debug the first 
time it happens unwillingly (maybe the sysadmin was changing some config 
on the server and suddenly the everything stops working and he needs to 
restart the nfs client to restore things but this is scarcely 
intuitive...). +1 for simply providing a clear-upfront option for using 
numeric UIDs/GIDs.

Thanks for your understanding :-)

Re: NFSv4 behaviour on unknown users

[Trond Myklebust]

On Tue, 2010-11-30 at 12:44 +0100, Spelic wrote:
> On 11/30/2010 01:02 AM, Spencer Shepler wrote:
> >> It would not be backwards compatible: the linux server will currently
> >> reject any uid/gid usage by the client.
> >>
> >> That said, I can imagine that for 'sec=sys', we might be able to change
> >> the client to use the uid/gid format by default, and then change back to
> >> doing name@domain upon receiving the first NFS4ERR_BADOWNER error from the
> >> server.
> >> It the server changes to match this, then that might suffice solve the
> >> current problem that we have with doing nfsroot on NFSv4...
> >>      
> > IMO: I wouldn't worry about the mixed scenarios to start with.
> > Provide the option on the client and server to use the straight-up
> > uid/gid to string mappings and this will satisfy these simple
> > deployments that are or will have trouble.
> >    
> 
> +1 for this.  Changing mapping on the fly at the first NFS4ERR_BADOWNER 
> received does not look very reliable to me: is scarcely controllable by 
> the sysadmin and is gonna make the thing a headache to debug the first 
> time it happens unwillingly (maybe the sysadmin was changing some config 
> on the server and suddenly the everything stops working and he needs to 
> restart the nfs client to restore things but this is scarcely 
> intuitive...). +1 for simply providing a clear-upfront option for using 
> numeric UIDs/GIDs.
> 
> Thanks for your understanding :-)

Sorry, but BADOWNER is an error that means "I don't get it" and the spec
_is_ adamant about what the client should do. This is a take it or leave
it: I'm not going to waste a lot of time and effort on this.

Trond

-- 
Trond Myklebust
Linux NFS client maintainer

NetApp
Trond.Myklebust@netapp.com
www.netapp.com

Re: NFSv4 behaviour on unknown users

[Boaz Harrosh]

On 11/30/2010 03:04 PM, Trond Myklebust wrote:
> On Tue, 2010-11-30 at 12:44 +0100, Spelic wrote:
>> On 11/30/2010 01:02 AM, Spencer Shepler wrote:
>>>> It would not be backwards compatible: the linux server will currently
>>>> reject any uid/gid usage by the client.
>>>>
>>>> That said, I can imagine that for 'sec=sys', we might be able to change
>>>> the client to use the uid/gid format by default, and then change back to
>>>> doing name@domain upon receiving the first NFS4ERR_BADOWNER error from the
>>>> server.
>>>> It the server changes to match this, then that might suffice solve the
>>>> current problem that we have with doing nfsroot on NFSv4...
>>>>      
>>> IMO: I wouldn't worry about the mixed scenarios to start with.
>>> Provide the option on the client and server to use the straight-up
>>> uid/gid to string mappings and this will satisfy these simple
>>> deployments that are or will have trouble.
>>>    
>>
>> +1 for this.  Changing mapping on the fly at the first NFS4ERR_BADOWNER 
>> received does not look very reliable to me: is scarcely controllable by 
>> the sysadmin and is gonna make the thing a headache to debug the first 
>> time it happens unwillingly (maybe the sysadmin was changing some config 
>> on the server and suddenly the everything stops working and he needs to 
>> restart the nfs client to restore things but this is scarcely 
>> intuitive...). +1 for simply providing a clear-upfront option for using 
>> numeric UIDs/GIDs.
>>
>> Thanks for your understanding :-)
> 
> Sorry, but BADOWNER is an error that means "I don't get it" and the spec
> _is_ adamant about what the client should do. This is a take it or leave
> it: I'm not going to waste a lot of time and effort on this.
> 

Perhaps a BIG FAT message in dmsg should help the poor admin investigating
the matter.

Thanks
> Trond
> 

RE: NFSv4 behaviour on unknown users

[Daniel.Muntz]

I agree, no change is necessary, but I still don't like the wording of this paragraph :-)

   To avoid this mechanism being used to subvert user and
   group translation, so that a client might pass all of the owners and
   groups in numeric form, a server SHOULD return an NFS4ERR_BADOWNER
   error when there is a valid translation for the user or owner
   designated in this way.  In that case, the client must use the
   appropriate name@domain string and not the special form for
   compatibility."

  -Dan

-----Original Message-----
From: Spencer Shepler [mailto:spencer.shepler@gmail.com] 
Sent: Monday, November 29, 2010 2:58 PM
To: Muntz, Daniel; Trond.Myklebust@netapp.com; spelic@shiftmail.org
Cc: linux-nfs@vger.kernel.org
Subject: RE: NFSv4 behaviour on unknown users


Dan,

A change to the NFSv4.0 and NFSv4.1 RFCs is unnecessary.
What you suggest can be implemented today and still adhere
to the RFC text.  From RFC3530 (section 4.8) and RFC5661 (section 5.9)
the following text is quoted:

"  In the case where there is no translation available to the client or
   server, the attribute value will be constructed without the "@".
   Therefore, the absence of the @ from the owner or owner_group
   attribute signifies that no translation was available at the sender
   and that the receiver of the attribute should not use that string as
   a basis for translation into its own internal format.  Even though
   the attribute value cannot be translated, it may still be useful.  In
   the case of a client, the attribute string may be used for local
   display of ownership.

   To provide a greater degree of compatibility with NFSv3, which
   identified users and groups by 32-bit unsigned user identifiers and
   group identifiers, owner and group strings that consist of decimal
   numeric values with no leading zeros can be given a special
   interpretation by clients and servers that choose to provide such
   support.  The receiver may treat such a user or group string as
   representing the same user as would be represented by an NFSv3 uid or
   gid having the corresponding numeric value.  A server is not
   obligated to accept such a string, but may return an NFS4ERR_BADOWNER
   instead.  To avoid this mechanism being used to subvert user and
   group translation, so that a client might pass all of the owners and
   groups in numeric form, a server SHOULD return an NFS4ERR_BADOWNER
   error when there is a valid translation for the user or owner
   designated in this way.  In that case, the client must use the
   appropriate name@domain string and not the special form for
   compatibility."


I read this that if the implementation or administrator chooses
to op-out of the user@domain mapping, it may do so and the client
and server have a method available to them to communicate traditiona
uid/gid.

So, all that is needed now it seems is some code to provide the
option to the admin or as you suggest, change the default.

Spencer


> -----Original Message-----
> From: linux-nfs-owner@vger.kernel.org [mailto:linux-nfs-
> owner@vger.kernel.org] On Behalf Of Daniel.Muntz@emc.com
> Sent: Monday, November 29, 2010 2:09 PM
> To: Trond.Myklebust@netapp.com; spelic@shiftmail.org
> Cc: linux-nfs@vger.kernel.org
> Subject: RE: NFSv4 behaviour on unknown users
> 
> Looks like it's time for my annual numeric uid rant...
> 
> IMHO this was the silliest decision in the v4 spec, and a frequent
> hindrance to users wanting to move from v3.  Once again, I'm going to
> suggest that the v4.x series officially support numeric uid/gid strings as
> first-class user identifiers, rather than trying to force "name@domain" on
> systems that do not need this functionality, and are worse off for having
> to support it.  The fact that every OS needs different configuration to
> get it working just adds to the insanity.  Supply something that works
> (numeric id strings) as the default, but allow the name@domain
> "enhancement" for those who want it.  Then, everything just works, people
> seamlessly migrate to v4.x, and world peace is achieved.  There could even
> be an option to disable numeric id string support for those vehemently
> opposed to its existence, but at least in this case sysadmins have to go
> out of their way to make their system return nobody/nogroup for all users,
> rather than being the default behavior.
> 
>   -Dan
> 
> -----Original Message-----
> From: linux-nfs-owner@vger.kernel.org [mailto:linux-nfs-
> owner@vger.kernel.org] On Behalf Of Trond Myklebust
> Sent: Monday, November 29, 2010 10:23 AM
> To: Spelic
> Cc: linux-nfs@vger.kernel.org
> Subject: Re: NFSv4 behaviour on unknown users
> 
> On Mon, 2010-11-29 at 19:12 +0100, Spelic wrote:
> > Hello all
> > we recently moved to nfsv4 from v3.
> >
> > I'm currently using idmapd and not kerberos.
> >
> > I noticed that now, with idmapd (and with idmapd is the only way I
> > know for configuring nfsv4 for now), users that are not known at
> > server side are squashed to nobody / nogroup  (65534 / 65534).
> > And a chown by root from the client fails if the user is not known at
> > server side.
> >
> > That's a problem... now we need ldap everywhere...
> >
> > We were often using NFS for exporting some diskspace to machines on an
> > as-needed basis, so this new behaviour complicates the things greatly
> > for us :-/ It's almost easier to setup iSCSI targets now :-((
> >
> > Is there a way to have nfsv4 with the behaviour of users of nfsv3,
> > that is, using numeric IDs instead of the names, like: "nfsserver,
> > don't care if you don't know the user, just give me the numeric ID for
> the file..."
> 
> No. That is not allowed by the spec.
> 
> Trond
> --
> Trond Myklebust
> Linux NFS client maintainer
> 
> NetApp
> Trond.Myklebust@netapp.com
> www.netapp.com
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
> the body of a message to majordomo@vger.kernel.org More majordomo info at
> http://vger.kernel.org/majordomo-info.html
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
> the body of a message to majordomo@vger.kernel.org More majordomo info at
> http://vger.kernel.org/majordomo-info.html

RE: NFSv4 behaviour on unknown users

[Spencer Shepler]

That was written 10 years ago.  If the problem has not been solved
sufficiently to avoid complaints such as yours and others then
it is time to change the interpretation through implementation.

Spencer


> -----Original Message-----
> From: Daniel.Muntz@emc.com [mailto:Daniel.Muntz@emc.com]
> Sent: Monday, November 29, 2010 3:35 PM
> To: spencer.shepler@gmail.com; Trond.Myklebust@netapp.com;
> spelic@shiftmail.org
> Cc: linux-nfs@vger.kernel.org
> Subject: RE: NFSv4 behaviour on unknown users
> 
> I agree, no change is necessary, but I still don't like the wording of
> this paragraph :-)
> 
>    To avoid this mechanism being used to subvert user and
>    group translation, so that a client might pass all of the owners and
>    groups in numeric form, a server SHOULD return an NFS4ERR_BADOWNER
>    error when there is a valid translation for the user or owner
>    designated in this way.  In that case, the client must use the
>    appropriate name@domain string and not the special form for
>    compatibility."
> 
>   -Dan
> 
> -----Original Message-----
> From: Spencer Shepler [mailto:spencer.shepler@gmail.com]
> Sent: Monday, November 29, 2010 2:58 PM
> To: Muntz, Daniel; Trond.Myklebust@netapp.com; spelic@shiftmail.org
> Cc: linux-nfs@vger.kernel.org
> Subject: RE: NFSv4 behaviour on unknown users
> 
> 
> Dan,
> 
> A change to the NFSv4.0 and NFSv4.1 RFCs is unnecessary.
> What you suggest can be implemented today and still adhere
> to the RFC text.  From RFC3530 (section 4.8) and RFC5661 (section 5.9)
> the following text is quoted:
> 
> "  In the case where there is no translation available to the client or
>    server, the attribute value will be constructed without the "@".
>    Therefore, the absence of the @ from the owner or owner_group
>    attribute signifies that no translation was available at the sender
>    and that the receiver of the attribute should not use that string as
>    a basis for translation into its own internal format.  Even though
>    the attribute value cannot be translated, it may still be useful.  In
>    the case of a client, the attribute string may be used for local
>    display of ownership.
> 
>    To provide a greater degree of compatibility with NFSv3, which
>    identified users and groups by 32-bit unsigned user identifiers and
>    group identifiers, owner and group strings that consist of decimal
>    numeric values with no leading zeros can be given a special
>    interpretation by clients and servers that choose to provide such
>    support.  The receiver may treat such a user or group string as
>    representing the same user as would be represented by an NFSv3 uid or
>    gid having the corresponding numeric value.  A server is not
>    obligated to accept such a string, but may return an NFS4ERR_BADOWNER
>    instead.  To avoid this mechanism being used to subvert user and
>    group translation, so that a client might pass all of the owners and
>    groups in numeric form, a server SHOULD return an NFS4ERR_BADOWNER
>    error when there is a valid translation for the user or owner
>    designated in this way.  In that case, the client must use the
>    appropriate name@domain string and not the special form for
>    compatibility."
> 
> 
> I read this that if the implementation or administrator chooses
> to op-out of the user@domain mapping, it may do so and the client
> and server have a method available to them to communicate traditiona
> uid/gid.
> 
> So, all that is needed now it seems is some code to provide the
> option to the admin or as you suggest, change the default.
> 
> Spencer
> 
> 
> > -----Original Message-----
> > From: linux-nfs-owner@vger.kernel.org [mailto:linux-nfs-
> > owner@vger.kernel.org] On Behalf Of Daniel.Muntz@emc.com
> > Sent: Monday, November 29, 2010 2:09 PM
> > To: Trond.Myklebust@netapp.com; spelic@shiftmail.org
> > Cc: linux-nfs@vger.kernel.org
> > Subject: RE: NFSv4 behaviour on unknown users
> >
> > Looks like it's time for my annual numeric uid rant...
> >
> > IMHO this was the silliest decision in the v4 spec, and a frequent
> > hindrance to users wanting to move from v3.  Once again, I'm going to
> > suggest that the v4.x series officially support numeric uid/gid strings
> as
> > first-class user identifiers, rather than trying to force "name@domain"
> on
> > systems that do not need this functionality, and are worse off for
> having
> > to support it.  The fact that every OS needs different configuration to
> > get it working just adds to the insanity.  Supply something that works
> > (numeric id strings) as the default, but allow the name@domain
> > "enhancement" for those who want it.  Then, everything just works,
> people
> > seamlessly migrate to v4.x, and world peace is achieved.  There could
> even
> > be an option to disable numeric id string support for those vehemently
> > opposed to its existence, but at least in this case sysadmins have to go
> > out of their way to make their system return nobody/nogroup for all
> users,
> > rather than being the default behavior.
> >
> >   -Dan
> >
> > -----Original Message-----
> > From: linux-nfs-owner@vger.kernel.org [mailto:linux-nfs-
> > owner@vger.kernel.org] On Behalf Of Trond Myklebust
> > Sent: Monday, November 29, 2010 10:23 AM
> > To: Spelic
> > Cc: linux-nfs@vger.kernel.org
> > Subject: Re: NFSv4 behaviour on unknown users
> >
> > On Mon, 2010-11-29 at 19:12 +0100, Spelic wrote:
> > > Hello all
> > > we recently moved to nfsv4 from v3.
> > >
> > > I'm currently using idmapd and not kerberos.
> > >
> > > I noticed that now, with idmapd (and with idmapd is the only way I
> > > know for configuring nfsv4 for now), users that are not known at
> > > server side are squashed to nobody / nogroup  (65534 / 65534).
> > > And a chown by root from the client fails if the user is not known at
> > > server side.
> > >
> > > That's a problem... now we need ldap everywhere...
> > >
> > > We were often using NFS for exporting some diskspace to machines on an
> > > as-needed basis, so this new behaviour complicates the things greatly
> > > for us :-/ It's almost easier to setup iSCSI targets now :-((
> > >
> > > Is there a way to have nfsv4 with the behaviour of users of nfsv3,
> > > that is, using numeric IDs instead of the names, like: "nfsserver,
> > > don't care if you don't know the user, just give me the numeric ID for
> > the file..."
> >
> > No. That is not allowed by the spec.
> >
> > Trond
> > --
> > Trond Myklebust
> > Linux NFS client maintainer
> >
> > NetApp
> > Trond.Myklebust@netapp.com
> > www.netapp.com
> >
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
> > the body of a message to majordomo@vger.kernel.org More majordomo info
> at
> > http://vger.kernel.org/majordomo-info.html
> >
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
> > the body of a message to majordomo@vger.kernel.org More majordomo info
> at
> > http://vger.kernel.org/majordomo-info.html
>