Hi all,
While investigating a bug report from our customer where NFSv4 name to
id mapping fails on the NFSv4 client (and maps to 'nobody') if a user or
group name contains non-ASCII characters (in this case it was Umlaut
characters) figured out we limit the characters to ASCII.
We seem to do this intentionally in utils/idmapd/idmapd.c: imconv()
...
case IDMAP_CONV_NAMETOID:
if (validateascii(im->im_name, sizeof(im->im_name)) == -1) {
im->im_status |= IDMAP_STATUS_INVALIDMSG;
return;
}
...
with the validateacsii() function. I'm not sure why we had to limit the
characters in the NFSv4 domain name to ASCII only. If I have to guess:
- perhaps it is risky because the shell might expand some characters?
- Non-ASCII characters might have trouble between sharing systems
that may use different encodings
- to remain consistent with the tools like `groupadd' which considers
a name with these characters as Invalid names (not sure why
`groupadd' does so)
However, there seems to be a valid use case for allowing such
characters. For e.g. If Active Directory or LDAP is being used for
authentication, both of them seem to allow Umlaut characters. When used
together with such directory services, idmapd would end up mapping those
users or groups to 'nobody'.
So my questions are:
1) What is the reason behind not allowing non-ASCII characters?
2) Is the limitation historical and is not relevant now? In such case
can we remove this check?
3) Would it make sense to allow atleast some UTF-8 characters that may
be non-risky?
Thanks
--
Suresh Jayaraman
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
