[X2Go-Dev] Bug#1229: x2go rejects usernames starting with digits, incorrectly

[Norman Gray]

Package: x2goserver
Version: 4.0.1.20

At present, x2goserver sanitises usernames with a regexp in x2goutils.pm 
and in x2gosqlitewrapper.pl (same in both places).  That's:

     if ($string =~ 
/^([a-zA-Z\_][a-zA-Z0-9\_\-\.\@]{0,47}[\$]?)\-([\d]{2,4})\-([\d]{9,12})\_[a-zA-Z0-9\_\-\.]*\_dp[\d]{1,2}$/) 
{

A username of, eg, '1234567x' fails this test, and the x2go session 
fails to start.  This is a valid username on CentOS (which is the OS I'm 
using in this case, but CentOS is far from unique here), therefore such 
a username should _not_ be rejected.

I have verified that the above code is indeed the source of my login 
problems, since if I hack the two files above, to have the regexp start 
with [a-zA-Z0-9\_], then my users can log in without difficulty.  This 
hacking is obviously not a great solution.

An alternative test would be to use getpwent(3).  This would verify that 
the proffered username is valid, absolutely authoritatively, without 
making any assumptions about what is or isn't valid on the current 
platform.  x2go should not second-guess getpwent(3).

In Perl terms, the above test could be replace with:

     $uid = getpwnam($string);
     if ($uid) {
         # username is OK
     } else {
         # user $string does not exist
     }

Note that the test may in fact be redundant, since if this code is being 
run, then the corresponding user has already logged on to the system, so 
that the username has already been verified as valid and existing.

Other observations:

   * If the system (or specifically getpwent) regards a given username 
as valid, then it will be valid for calls to other local library calls.  
If this were not the case, that would be a major system bug on that 
platform.

   * POSIX/Single Unix says of the username simply "To be portable 
across systems conforming to POSIX.1-2008, the value is composed of 
characters from the portable filename character set. The <hyphen-minus> 
character should not be used as the first character of a portable user 
name." (see <http://pubs.opengroup.org/onlinepubs/9699919799/>, 
paragraph 3.437)

   * The Debian useradd(8) page recommends something matching 
/^[a-z_][a-z0-9_-]*$/, but goes on to say "On Debian, the only 
constraints are that usernames must neither start with a dash ('-') nor 
contain a colon (':') or a whitespace (space: ' ', end of line: '\n', 
tabulation: '\t', etc.). Note that using a slash ('/') may break the 
default algorithm for the definition of the user's home directory." (see 
eg <https://www.unix.com/man-page/linux/8/useradd/>)

   * The corresponding RedHat/CentOS manpage doesn't even include that, 
and instead says only "Usernames may only be up to 32 characters long."  
FreeBSD is similarly laid-back about the username.

   * The GNU Coreutils manual 
<https://www.gnu.org/software/coreutils/manual/coreutils.html#Disambiguating-names-and-IDs> 
which explicitly acknowledges that an all-digits username is legitimate, 
and describes how the coreutils resolve the potential ambiguity.

   * It may have been true in the past that some unixes objected to 
all-digits usernames.  I personally am not aware of any current unixes 
which do so.

   * It is not an option to change the usernames ('1234567x') on this 
system, since they are widely deployed in other systems.  Also, they're 
valid username as far as the local system is concerned.

This issue was discussed on the user list a little while ago 
<http://lists.x2go.org/pipermail/x2go-user/2015-April/003161.html> 
(that's what gave me the aha!).  There, Mihai Moldovan said "That's 
non-standard-compliant and you're basically on your own when doing 
"funky stuff"."  To be clear, I agree such usernames are less than 
ideal, but I don't think they count as funky or non-compliant.

The issue was discussed on the x2go-dev list more recently, starting at 
<http://lists.x2go.org/pipermail/x2go-dev/2017-October/012140.html>

Best wishes,

Norman


-- 
Norman Gray  :  https://nxg.me.uk