Skip to contentSkip to conversation

idmapd doesn't map if the name (user or group) contains UTF8 characters

DISCUSSION Suresh Jayaraman 2 participants 2 messages Dec 13, 2012

Subsystems (2)
lore
Share & tools
lore
#0 lore raw

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

Signature · 1 line
Suresh Jayaraman
#1 lore raw
Quoted 34 lines · Suresh Jayaraman

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'.

Quoted 3 lines

So my questions are:

1) What is the reason behind not allowing non-ASCII characters?

I don't know why it's there either. I don't think there's any reason the kernel or other NFS code needs the check.

Quoted 4 lines

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?

I'd suggest just throwing away the check.

Even if we were to check for something else (like UTF-8, which is what the v4 specs actually want), idmapd doesn't seem like the right place to enforce restrictions on names. Once the system has allowed a name it's too late to be complaining about it here.

--b.