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
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-
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
[email protected]
http://www.netapp.com
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: [email protected] [mailto:[email protected]]
> Sent: Monday, November 29, 2010 3:35 PM
> To: [email protected]; [email protected];
> [email protected]
> Cc: [email protected]
> 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:[email protected]]
> Sent: Monday, November 29, 2010 2:58 PM
> To: Muntz, Daniel; [email protected]; [email protected]
> Cc: [email protected]
> 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: [email protected] [mailto:linux-nfs-
> > [email protected]] On Behalf Of [email protected]
> > Sent: Monday, November 29, 2010 2:09 PM
> > To: [email protected]; [email protected]
> > Cc: [email protected]
> > 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: [email protected] [mailto:linux-nfs-
> > [email protected]] On Behalf Of Trond Myklebust
> > Sent: Monday, November 29, 2010 10:23 AM
> > To: Spelic
> > Cc: [email protected]
> > 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
> > [email protected]
> > http://www.netapp.com
> >
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
> > the body of a message to [email protected] 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 [email protected] More majordomo info
> at
> > http://vger.kernel.org/majordomo-info.html
>
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
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: [email protected] [mailto:linux-nfs-
> > [email protected]] On Behalf Of [email protected]
> > Sent: Monday, November 29, 2010 2:09 PM
> > To: [email protected]; [email protected]
> > Cc: [email protected]
> > 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: [email protected] [mailto:linux-nfs-
> > [email protected]] On Behalf Of Trond Myklebust
> > Sent: Monday, November 29, 2010 10:23 AM
> > To: Spelic
> > Cc: [email protected]
> > 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
> > [email protected]
> > http://www.netapp.com
> >
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
> > the body of a message to [email protected] 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 [email protected] More majordomo info at
> > http://vger.kernel.org/majordomo-info.html
>
--
Trond Myklebust
Linux NFS client maintainer
NetApp
[email protected]
http://www.netapp.com
> -----Original Message-----
> From: Trond Myklebust [mailto:[email protected]]
> Sent: Monday, November 29, 2010 3:26 PM
> To: Spencer Shepler
> Cc: [email protected]; [email protected]; [email protected]
> 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
> [email protected]
> http://www.netapp.com
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
>
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
[email protected]
http://www.netapp.com
> -----Original Message-----
> From: Trond Myklebust [mailto:[email protected]]
> Sent: Monday, November 29, 2010 3:16 PM
> To: Spencer Shepler
> Cc: [email protected]; [email protected]; [email protected]
> 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: [email protected] [mailto:linux-nfs-
> > > [email protected]] On Behalf Of [email protected]
> > > Sent: Monday, November 29, 2010 2:09 PM
> > > To: [email protected]; [email protected]
> > > Cc: [email protected]
> > > 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: [email protected] [mailto:linux-nfs-
> > > [email protected]] On Behalf Of Trond Myklebust
> > > Sent: Monday, November 29, 2010 10:23 AM
> > > To: Spelic
> > > Cc: [email protected]
> > > 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
> > > [email protected]
> > > http://www.netapp.com
> > >
> > > --
> > > To unsubscribe from this list: send the line "unsubscribe linux-nfs"
> > > in the body of a message to [email protected] 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 [email protected] More majordomo
> > > info at http://vger.kernel.org/majordomo-info.html
> >
>
> --
> Trond Myklebust
> Linux NFS client maintainer
>
> NetApp
> [email protected]
> http://www.netapp.com
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.
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:[email protected]]
Sent: Monday, November 29, 2010 2:58 PM
To: Muntz, Daniel; [email protected]; [email protected]
Cc: [email protected]
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: [email protected] [mailto:linux-nfs-
> [email protected]] On Behalf Of [email protected]
> Sent: Monday, November 29, 2010 2:09 PM
> To: [email protected]; [email protected]
> Cc: [email protected]
> 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: [email protected] [mailto:linux-nfs-
> [email protected]] On Behalf Of Trond Myklebust
> Sent: Monday, November 29, 2010 10:23 AM
> To: Spelic
> Cc: [email protected]
> 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
> [email protected]
> http://www.netapp.com
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
> the body of a message to [email protected] 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 [email protected] More majordomo info at
> http://vger.kernel.org/majordomo-info.html
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: [email protected] [mailto:[email protected]] On Behalf Of Trond Myklebust
Sent: Monday, November 29, 2010 10:23 AM
To: Spelic
Cc: [email protected]
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
[email protected]
http://www.netapp.com
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 [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> -----Original Message-----
> From: Trond Myklebust [mailto:[email protected]]
<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
> [email protected]
> http://www.netapp.com
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
[email protected]
http://www.netapp.com
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: [email protected] [mailto:linux-nfs-
> [email protected]] On Behalf Of [email protected]
> Sent: Monday, November 29, 2010 2:09 PM
> To: [email protected]; [email protected]
> Cc: [email protected]
> 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: [email protected] [mailto:linux-nfs-
> [email protected]] On Behalf Of Trond Myklebust
> Sent: Monday, November 29, 2010 10:23 AM
> To: Spelic
> Cc: [email protected]
> 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
> [email protected]
> http://www.netapp.com
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
> the body of a message to [email protected] 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 [email protected] More majordomo info at
> http://vger.kernel.org/majordomo-info.html
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
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
[email protected]
http://www.netapp.com
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 :-)
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
[email protected]
http://www.netapp.com
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
[email protected]
http://www.netapp.com
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.
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.
On Tue, 30 Nov 2010 17:36:27 -0500 "J. Bruce Fields" <[email protected]>
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 [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
On Mon, 2010-11-29 at 15:30 -0800, Spencer Shepler wrote:
>
> > -----Original Message-----
> > From: Trond Myklebust [mailto:[email protected]]
> > Sent: Monday, November 29, 2010 3:26 PM
> > To: Spencer Shepler
> > Cc: [email protected]; [email protected]; [email protected]
> > 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
[email protected]
http://www.netapp.com
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.
On Tue, 30 Nov 2010 22:10:02 -0500 Trond Myklebust
<[email protected]> 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
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 [email protected]
> > 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 [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Trond Myklebust
Linux NFS client maintainer
NetApp
[email protected]
http://www.netapp.com
> -----Original Message-----
> From: [email protected] [mailto:linux-nfs-
> [email protected]] On Behalf Of Trond Myklebust
> Sent: Thursday, December 02, 2010 3:18 PM
> To: Thomas Haynes
> Cc: J. Bruce Fields; Spelic; [email protected]
> 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 [email protected] 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
On Thu, Dec 02, 2010 at 03:28:48PM -0800, Spencer Shepler wrote:
>
>
> > -----Original Message-----
> > From: [email protected] [mailto:linux-nfs-
> > [email protected]] On Behalf Of Trond Myklebust
> > Sent: Thursday, December 02, 2010 3:18 PM
> > To: Thomas Haynes
> > Cc: J. Bruce Fields; Spelic; [email protected]
> > 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 [email protected] 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.
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.
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.
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 [email protected]
> 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.
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?
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 [email protected]
> > 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
[email protected]
http://www.netapp.com