[arch-general] User/group name restrictions
Hi This is something I gotten used to live with for a very long time now, patching the shadow package every time it is updated to allow capitals in the user/group names. I've often meant to write in to ask why and this is that glorious day. Why is it that uppercase letters are not allowed in user/group names in Arch Linux please. It's not that I'm anal about everything, but I was always brought up with the rule that a person's name should be written with their appropriate capital letters and not to do so is a deliberate mark of disrespect at the owner's address. So imagine my chagrin if I'd have to stare at my terminal all day long with such deliberate cheekiness staring in my face 😜 Thanks Andy
On 5/23/19 3:15 PM, Andy Pieters wrote:
Hi
This is something I gotten used to live with for a very long time now, patching the shadow package every time it is updated to allow capitals in the user/group names.
I've often meant to write in to ask why and this is that glorious day.
Why is it that uppercase letters are not allowed in user/group names in Arch Linux please.
It's not that I'm anal about everything, but I was always brought up with the rule that a person's name should be written with their appropriate capital letters and not to do so is a deliberate mark of disrespect at the owner's address.
So imagine my chagrin if I'd have to stare at my terminal all day long with such deliberate cheekiness staring in my face 😜
Is this a trick question? Perhaps you wish your terminal prompt to contain the User name (GECOS field) of /etc/passwd, rather than the login name. I presume so, since you state that you are anal about proper names, and a login name will never, ever be a proper name until it also contains the space in between the first and last name -- and for many parts of the world, it also has to contain completely arbitrary bytes that aren't part of the latin alphabet. Therefore it logically follows that your computer's symbolic codename will continue to be unsuitable as a *display* name even if you were able to use capitals in it. Not sure why you think it is Arch Linux's job to decide whether Unix login names should contain whichever type of character. However you may rest assured that this has been the case as upstream intended since 2001-11-07: https://github.com/shadow-maint/shadow/commit/9db6abfa42c946b4046f4b2fe67dc4... (This is a CVS import which was done in 2007, the other date can be seen in the changelog.) If you're actually asking why Debian provides a downstream patch that permits nonstandard login names, I don't know or care. ... Given that your initial post does specifically state that you are patching the package in order to allow it, I will assume that nothing I just said about upstream's intentions is remotely surprising to you -- you would have to know that it's enforced in libmisc/chkname.c in order to patch it, soooo... may I ask why you posted to the list asking why it is not allowed "in Arch Linux", rather than "in the upstream, distribution-agnostic shadow-maint software"? It seems almost disingenuous to put it that way, and you are the person who would know better than most arch-general readers that it's not actually something Arch Linux is doing. Why be misleading? It will only result in people having no idea what you are talking about, assuming your public statements about this being some form of Arch Linux configuration are accurate, and giving you uninformed answers as a result. This is hardly conducive to your desired goal to find out why. -- Eli Schwartz Bug Wrangler and Trusted User
On Thu, 23 May 2019 19:08:22 -0400, Eli Schwartz via arch-general wrote:
On 5/23/19 3:15 PM, Andy Pieters wrote:
Hi
This is something I gotten used to live with for a very long time now, patching the shadow package every time it is updated to allow capitals in the user/group names.
I've often meant to write in to ask why and this is that glorious day.
Why is it that uppercase letters are not allowed in user/group names in Arch Linux please.
It's not that I'm anal about everything, but I was always brought up with the rule that a person's name should be written with their appropriate capital letters and not to do so is a deliberate mark of disrespect at the owner's address.
So imagine my chagrin if I'd have to stare at my terminal all day long with such deliberate cheekiness staring in my face 😜
Is this a trick question? Perhaps you wish your terminal prompt to contain the User name (GECOS field) of /etc/passwd, rather than the login name. I presume so, since you state that you are anal about proper names, and a login name will never, ever be a proper name until it also contains the space in between the first and last name -- and for many parts of the world, it also has to contain completely arbitrary bytes that aren't part of the latin alphabet. Therefore it logically follows that your computer's symbolic codename will continue to be unsuitable as a *display* name even if you were able to use capitals in it.
Not sure why you think it is Arch Linux's job to decide whether Unix login names should contain whichever type of character. However you may rest assured that this has been the case as upstream intended since 2001-11-07: https://github.com/shadow-maint/shadow/commit/9db6abfa42c946b4046f4b2fe67dc4... (This is a CVS import which was done in 2007, the other date can be seen in the changelog.)
If you're actually asking why Debian provides a downstream patch that permits nonstandard login names, I don't know or care.
...
Given that your initial post does specifically state that you are patching the package in order to allow it, I will assume that nothing I just said about upstream's intentions is remotely surprising to you -- you would have to know that it's enforced in libmisc/chkname.c in order to patch it, soooo... may I ask why you posted to the list asking why it is not allowed "in Arch Linux", rather than "in the upstream, distribution-agnostic shadow-maint software"?
It seems almost disingenuous to put it that way, and you are the person who would know better than most arch-general readers that it's not actually something Arch Linux is doing. Why be misleading? It will only result in people having no idea what you are talking about, assuming your public statements about this being some form of Arch Linux configuration are accurate, and giving you uninformed answers as a result. This is hardly conducive to your desired goal to find out why.
The following (taken from http://www.catb.org/~esr/faqs/things-every-hacker-once-knew/) may be relevant here: "The very earliest VDTs, like the ASR-33 before them, could form only upper-case letters. An interesting hangover from these devices was that, even though most VDTs made after 1975 could form lower-case letters, Unix (and Linux as late as 2018) responded to a login beginning with an upper-case letter by switching to a mode which upcased all input. If you create an account with this sort of login name and a mixed-case password, hilarity ensues. If the password is upper-case the hilarity is less desperate but still confusing for the user." I've not tried this on my current Arch install to see if it's still true in 2019, but maybe disallowing uppercase in the user/group names is an attempt to stop that being a problem.
Op vr 24 mei 2019 07:52 schreef Spencer Collyer : [...] The following (taken from
http://www.catb.org/~esr/faqs/things-every-hacker-once-knew/) may be
relevant here: "The very earliest VDTs, like the ASR-33 before them, could form only
upper-case letters. An interesting hangover from these devices was that,
even though most VDTs made after 1975 could form lower-case letters, Unix
(and Linux as late as 2018) responded to a login beginning with an
upper-case letter by switching to a mode which upcased all input. If you
create an account with this sort of login name and a mixed-case password,
hilarity ensues. If the password is upper-case the hilarity is less
desperate but still confusing for the user." OT:
In a former job, we had an HP-Ux server, that did have this "feature".
And the fun with "special" characters like @ and # (erase), which were
handled different between passwd and login...
Fun times.
Mvg, Guus
On Fri, May 24, 2019 at 12:08 AM Eli Schwartz via arch-general < arch-general@archlinux.org> wrote:
Given that your initial post does specifically state that you are patching the package in order to allow it, I will assume that nothing I just said about upstream's intentions is remotely surprising to you -- you would have to know that it's enforced in libmisc/chkname.c in order to patch it, soooo... may I ask why you posted to the list asking why it is not allowed "in Arch Linux", rather than "in the upstream, distribution-agnostic shadow-maint software"?
What is obvious to me now is that I formed the wrong opinion years ago when I had just started to use Arch (coming from a distro that did allow uppercase user names) and now when I finally decided to go and ask the question I didn't revisit that opinion and I should have because if I had bothered to go over things again I would have come to the same conclusion. This wasn't a trick question or a deliberate intent to mislead just my own failing in this matter
On 5/24/19 4:03 AM, Andy Pieters wrote:
On Fri, May 24, 2019 at 12:08 AM Eli Schwartz via arch-general < arch-general@archlinux.org> wrote:
Given that your initial post does specifically state that you are patching the package in order to allow it, I will assume that nothing I just said about upstream's intentions is remotely surprising to you -- you would have to know that it's enforced in libmisc/chkname.c in order to patch it, soooo... may I ask why you posted to the list asking why it is not allowed "in Arch Linux", rather than "in the upstream, distribution-agnostic shadow-maint software"?
What is obvious to me now is that I formed the wrong opinion years ago when I had just started to use Arch (coming from a distro that did allow uppercase user names) and now when I finally decided to go and ask the question I didn't revisit that opinion and I should have because if I had bothered to go over things again I would have come to the same conclusion.
This wasn't a trick question or a deliberate intent to mislead just my own failing in this matter
Okay, but the point I'm trying to make here is that if you have "for a very long time" patched the sources to allow it, you know where the check comes from. I'm not saying you were being deliberately misleading, but it was still confusing nonetheless -- and personally, I eventually found where it was being enforced by checking Debian's shadow package to see which new features they patched in downstream. ... BTW I'm serious about using the GECOS field for the display name, you could for example use the following in your .profile: REALNAME=$(getent passwd "$USER" | cut -d: -f5 | cut -d, -f1 ) And then embed that in your prompt string. -- Eli Schwartz Bug Wrangler and Trusted User
On 5/23/19 7:08 PM, Eli Schwartz wrote:
Given that your initial post does specifically state that you are patching the package in order to allow it, I will assume that nothing I just said about upstream's intentions is remotely surprising to you -- you would have to know that it's enforced in libmisc/chkname.c in order to patch it, soooo... may I ask why you posted to the list asking why it is not allowed "in Arch Linux", rather than "in the upstream, distribution-agnostic shadow-maint software"?
It seems almost disingenuous to put it that way, and you are the person who would know better than most arch-general readers that it's not actually something Arch Linux is doing. Why be misleading? It will only result in people having no idea what you are talking about, assuming your public statements about this being some form of Arch Linux configuration are accurate, and giving you uninformed answers as a result. This is hardly conducive to your desired goal to find out why.
Just wanted to clarify -- I did not think you were being deliberately misleading here. It just seemed like an oversight, possibly assuming other readers also know exactly how the shadow package is constructed, and I wish to highlight the importance of making sure that questions are asked with enough background to allow others to grok what is actually going on. -- Eli Schwartz Bug Wrangler and Trusted User
participants (4)
-
Andy Pieters
-
Eli Schwartz
-
Guus Snijders
-
Spencer Collyer