On 12/25/2016 06:30 PM, G. Schlisio wrote:
>> I tried that on archlinux. The above program still produces EINVAL for
>> login names between 32 and 255 inclusive.
>>
>> _SC_LOGIN_NAME_MAX is 256 on that platform.
>>
>> John
>>
> hi,
>
> earlier i tried with literal "AAAAAA", which was probably not what you
> meant.
> it produced a "not found".
> using an affected user name yields (with both your programs):
> getpwnam_r: Invalid argument
> while an existing shell account yields its UID:
> Name: ; UID: 1001
>
> for me its not clear whats the difference between a literal AAAA string
> and an existing username not in passwd (why one produces an error and
> one doesnt).
>
> sorry for not reading carefully earlier…
>
> georg
Hi Georg
thanks for that, so at least we have consistent behaviour which is good.
I had got the AAAAAAAA from your logging without realizing it was
anonymized.
Now the problem to solve is why the user names you are testing with give
the invalid argument. One reason would be if they are longer than 31
chars. But if they are not then there is something else, for example do
they contain a dot or some other character that archlinux does not
accept in user names?
At this point I suspect that your system is providing EINVAL for any
name that could not be a valid local username (with one exception that
it allows uppercase which is not valid in usernames). According to the
archlinux useradd manual:
"Usernames must start with a lower case letter or an underscore,
followed by lower case letters, digits,
underscores, or dashes. They can end with a dollar sign. In
regular expression terms:
[a-z_][a-z0-9_-]*[$]?
Usernames may only be up to 32 characters long."
This is a problem because the getpwnam_r routine on archlinux is
deviating from the specifications by not always returning 0 for users
that are not found. This should be addressed in archlinux or upstream in
glibc. Can you take it back to the archlinux list and see if you can get
this addressed?
John
