Iirc systemd refused usernames starting with a number. There was a huge discussion in the systemd bugtracker but I don't remeber the outcome anymore.
Part of the problem is that commands accept both usernames and userid AS parameters and there just be some clear way to distinguish those two.
I suggest checking the systemd bugtracker before starting another discussion here ;-) See here: https://github.com/systemd/systemd/issues/6237
Uli
Am 24.10.2017 21:42 schrieb "Norman Gray" <gray@nxg.name>:
Greetings.
[I'm happy to submit this as a bug at bugs.x2go.org, but < https://wiki.x2go.org/doku.php/wiki:bugs> recommends discussing potential bugs here beforehand]
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. I believe such a username should not fail.
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.
I myself think that a username like '1234567x' is asking for at least a little bit of trouble, but those are the networked usernames I'm having to deal with, so that trouble is not of my asking. Also, I suspect that the trailing character is there precisely in order to avoid this matching /^[0-9]+$/, and thus to be interpretable as a number.
This does appear to be 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.
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 think such usernames are less than ideal, but I don't think they count as funky or non-compliant.
As a distinct but related matter, when a failing username is rejected by this test, the session doesn't fail, but simply seems to hang, giving no feedback about the problem, nor, as far as I can see, reporting anything in the logs. Whatever the decision about this report, it would be useful to fail in a more communicative way.
I'd be interested in your views.
Best wishes,
Norman
-- Norman Gray : https://nxg.me.uk
x2go-dev mailing list x2go-dev@lists.x2go.org https://lists.x2go.org/listinfo/x2go-dev
Uli (and all), hello.
On 24 Oct 2017, at 21:54, Ulrich Sibiller wrote:
Iirc systemd refused usernames starting with a number. There was a huge discussion in the systemd bugtracker but I don't remeber the outcome anymore.
Thanks for the pointer.
There seem to have been two intermixed discussions there, first about whether '0day' was a valid username, and secondly about systemd's behaviour when it encountered such a username.
Early in the discussion, 'poettering' asserts that '"0day" is not a valid username' and 'the username is clearly not valid', without pointing to any justification for either assertion. Neither assertion is supported by the POSIX/SingleUnix or Debian sources I mentioned earlier. In other words, I think poettering is simply wrong to assert that such a username is generally invalid.
Other participants in that discussion pointed to the Single Unix spec (which permits all-digit usernames), and to a passage in 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 ambiguity.
It may be that _some_ unixes deem a username which starts with a digit to be invalid, but it's clearly not universal. I'm not aware of any current unix where this is the case.
Note that (if I recall correctly) some unixes will work fine with an all-digits username, but the standard tool will not allow you to create such usernames (this might be true of Debian?).
Part of the problem is that commands accept both usernames and userid AS parameters and there just be some clear way to distinguish those two.
The coreutils manual attempts to match a string as a username (even if all digits) and as a numeric uid only if that fails. It says that 'POSIX requires [this]', but doesn't point to where (I couldn't find that requirement myself).
Now, in the case of the example there, a user_name_ of '42' really is asking/begging for trouble, but that library goes out of its way to process that as a valid username.
Best wishes,
Norman
-- Norman Gray : https://nxg.me.uk
Greetings.
On 24 Oct 2017, at 22:48, Norman Gray wrote:
It may be that _some_ unixes deem a username which starts with a digit to be invalid, but it's clearly not universal. I'm not aware of any current unix where this is the case.
And a further point, obvious in retrospect: by the time this code is being run, the user has already authenticated to the system, with the given username. Thus the username in question -- whatever its format, irrespective of any standards -- is necessarily a valid one, which therefore surely needs no more validation by the x2go code.
It may be that x2go needs to normalise the name for its own reasons, but as far as I can see it has no grounds for rejecting it.
Best wishes,
Norman
-- Norman Gray : https://nxg.me.uk
I think there even exists a bugreport for this.
I'm reluctant to allow all-numeric user names because of the ambiguity and the fact that we use the user name later for other stuff (e.g., for executing commands as the user account that started the session.) Assuming, that "the system libraries will get this stuff right" isn't very comforting in this kind of edge case.
User names that *start* with a digit (but also contain at least one other character of the portable file name set) don't have this ambiguity, so we probably could allow that.
Then again, this will likely cause problems with software like systemd and maybe other, too (like [commercial] authentication brokers that use LDAP or the like.)
All that said, I'd personally argue that just avoiding such naming schemes altogether and disallowing it in x2goserver is easier than handling the mess that might ensue if it were allowed.
Mihai
Am 25.10.2017 um 14:08 schrieb Mihai Moldovan:
All that said, I'd personally argue that just avoiding such naming schemes altogether and disallowing it in x2goserver is easier than handling the mess that might ensue if it were allowed.
Could we add a config entry somewhere, say /etc/x2go/somefileorother, where it says "ALLOW_NUMERIC_USERNAMES=false" as a default, and users that have the need to use such usernames can set it to true in that central location? Feel free to attach a warning message that enabling this is not recommended, may introduce errors and security issues (see systemd's "0day" account bug), HC SVNT DRACONES, yadda yadda yadda.
Kind Regards, Stefan Baur
-- BAUR-ITCS UG (haftungsbeschränkt) Geschäftsführer: Stefan Baur Eichenäckerweg 10, 89081 Ulm | Registergericht Ulm, HRB 724364 Fon/Fax 0731 40 34 66-36/-35 | USt-IdNr.: DE268653243
On Wed, Oct 25, 2017 at 2:08 PM, Mihai Moldovan <ionic@ionic.de> wrote:
I think there even exists a bugreport for this.
I'm reluctant to allow all-numeric user names because of the ambiguity and the fact that we use the user name later for other stuff (e.g., for executing commands as the user account that started the session.) Assuming, that "the system libraries will get this stuff right" isn't very comforting in this kind of edge case.
Well, Norman's point of "the user is already authenticated at the point where x2go kicks in" is valid. So why check the username at all?
Uli
Mihai and all, hello.
On 25 Oct 2017, at 13:08, Mihai Moldovan wrote:
I'm reluctant to allow all-numeric user names because of the ambiguity and the fact that we use the user name later for other stuff (e.g., for executing commands as the user account that started the session.) Assuming, that "the system libraries will get this stuff right" isn't very comforting in this kind of edge case.
I appreciate the nervousness -- my first instinct, also, would be to validate the username at some point like this.
However, I think the nervousness and the check are both misplaced. If x2go is being invoked with an all-digits username, then it _must_ be the case that the system libraries get this right, because they have _already_ got this right. It's not x2go's responsibility to object to a username that the rest of the system thinks is valid.
Indeed, it borders on the impertinent!
This is not an edge case: if x2go is being presented with an all-digits username, post-login, then it can reliably deduce that it is working on a system where an all-digits username is valid (and, as I mentioned earlier, I'm not aware of any current unixes, nor any published standard, where such a name isn't actually valid).
The fact that the only relevant standards (POSIX/SingleUnix and the Debian links I pointed to) deem all-digits to be a valid username means also that, to me, x2go has no ground to object to such a name.
Or, put another way, the idea that all-digits usernames are invalid is a superstition. It's a very widespread superstition (and might historically have been true), but a superstition nonetheless.
Then again, this will likely cause problems with software like systemd and maybe other, too (like [commercial] authentication brokers that use LDAP or the like.)
If systemd has a problem with a system-valid username, then that is a systemd problem, not the system's problem.
The usernames I'm dealing with are coming from an LDAP server.
All that said, I'd personally argue that just avoiding such naming schemes altogether...
I'm afraid that's out of the question. The LDAP server that's feeding me these usernames is happily feeding them out to hundreds of working systems across the campus. Reporting that 'x2go doesn't like your usernames' is going to get 'not a bug' attached to it, as fast as someone's mouse-finger can move.
Best wishes,
Norman
-- Norman Gray : https://nxg.me.uk
Greetings.
Tying up this thread, I've now reported this as a bug -- see <https://bugs.x2go.org/cgi-bin/bugreport.cgi?bug=1229>.
I've separately reported that the server doesn't produce useful feedback in this case (and I presume in other cases which fail validation for other reasons). That's <https://bugs.x2go.org/cgi-bin/bugreport.cgi?bug=1230>. I _think_ these are distinct issues, but feel free, of course, to merge them if I'm mistaken.
Best wishes,
Norman
-- Norman Gray : https://nxg.me.uk
-
Mihai Moldovan -
Norman Gray -
Stefan Baur -
Ulrich Sibiller -
Ulrich Sibiller