* idmapd client-side static mapping
@ 2012-07-12 13:54 Jiri Horky
2012-07-12 14:58 ` Steve Dickson
0 siblings, 1 reply; 3+ messages in thread
From: Jiri Horky @ 2012-07-12 13:54 UTC (permalink / raw)
To: linux-nfs
[-- Attachment #1: Type: text/plain, Size: 447 bytes --]
Hi,
man pages for idmapd.conf states possibility to use Static mapping.
Looking at the source code of libnfsidmap v0.24, it is clear that static
mappings are only valid for server side (svcgssd) which the man page
forgets to mention. Is there any specific reason why not to implement
the static resolution functions on the client side as well?
I would send a patch if there is a change it will be accepted.
Regards
Jiri Horky
[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 5659 bytes --]
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: idmapd client-side static mapping
2012-07-12 13:54 idmapd client-side static mapping Jiri Horky
@ 2012-07-12 14:58 ` Steve Dickson
2012-07-22 20:34 ` Jiri Horky
0 siblings, 1 reply; 3+ messages in thread
From: Steve Dickson @ 2012-07-12 14:58 UTC (permalink / raw)
To: Jiri Horky; +Cc: linux-nfs
On 07/12/2012 09:54 AM, Jiri Horky wrote:
> Hi,
>
> man pages for idmapd.conf states possibility to use Static mapping. Looking at the source code of libnfsidmap v0.24, it is clear that static mappings are only valid for server side (svcgssd) which the man page forgets to mention. Is there any specific reason why not to implement the static resolution functions on the client side as well?
That is a good question... I always wonders this myself....
>
> I would send a patch if there is a change it will be accepted.
There is only one way to find out! ;-)
steved.
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: idmapd client-side static mapping
2012-07-12 14:58 ` Steve Dickson
@ 2012-07-22 20:34 ` Jiri Horky
0 siblings, 0 replies; 3+ messages in thread
From: Jiri Horky @ 2012-07-22 20:34 UTC (permalink / raw)
To: Steve Dickson; +Cc: linux-nfs, du@cesnet.cz
Hi,
I sent the patch in the separated email and now I hope for the best :)
Some more notes: if one configures only the "Static" translation method
nowadays, any translation of id to name does not occur (since it is not
implemented), return code of the nfs4_uid_to_name() function will be 0
which is set by init function in libnfsidmap.c:357 and you get empty
string as the result which puzzles the client and completely freezes the
system. It can be triggered by e.g. issuing "chown 1000 /nfs4mnt/testfile".
I think that more correct behavior would be to return -ENOENT if there
are no plugins with a given translation function. This is not included
in the patch sent.
By the way, is there a reason why the function like nfs4_name_to_uid or
its "gid" partner does not return "nobody/nogroup" when it fails to do
the translation? On my system, it is set to a random value
(uninitialized int) in this case.
Jiri Horky
On 07/12/2012 04:58 PM, Steve Dickson wrote:
> On 07/12/2012 09:54 AM, Jiri Horky wrote:
>> Hi,
>>
>> man pages for idmapd.conf states possibility to use Static mapping. Looking at the source code of libnfsidmap v0.24, it is clear that static mappings are only valid for server side (svcgssd) which the man page forgets to mention. Is there any specific reason why not to implement the static resolution functions on the client side as well?
> That is a good question... I always wonders this myself....
>
>> I would send a patch if there is a change it will be accepted.
> There is only one way to find out! ;-)
>
> steved.
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2012-07-22 20:40 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2012-07-12 13:54 idmapd client-side static mapping Jiri Horky
2012-07-12 14:58 ` Steve Dickson
2012-07-22 20:34 ` Jiri Horky
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).