Where are the login format rules? (SOLVED)

[lonnieb]

Recently I updated my PCLOS laptop (after a long time left alone) and ran into an interesting issue. My login no longer worked. When I dug around, I discovered that PAM doesn't like logins that start with a number anymore (I've used the same login across all my systems since SVR3 in 1989, and it started with a number).

Does anyone know where this account login format rule is defined? I've searched all over Google using several dozen combinations of terminology, and get nothing related.

Thanks,
Lonnie

[rubentje1991]

Is it possible that the module is changed?
=> I don't know for sure, but I think that pam uses different modules; one for each type of credentials / logging on
And you would like to change such a module?....

However; if you're using KDE (and thus - most of the times - kdm to log in the system), check that the keys you press are really typed in into the password field....
=> not so long ago, we had an issue with typing a password that only consisted of numeric characters; and the first character, we had to type twice, because the first press was never accepted (all the other characters, we just had to type them once...)

[Neal ManBear]

Recently I updated my PCLOS laptop (after a long time left alone)

Thanks,
Lonnie

     
How long did you go without updating?      
Which version of PCLinuxOS do you have installed? If it is a 2010 release, have you run aptupgrade?     

[TerryN]

The restriction seems to be hard coded in the PAM modules on Linux distros that use Openwall tcb package.  As far as I can tell it has been that way for some considerable time.

From http://cvsweb.openwall.com/cgi/cvsweb.cgi/Owl/packages/tcb/tcb/pam_tcb/pam_unix_auth.c?rev=1.6

Code: [Select]

/* get the username */
retval = pam_get_user(pamh, &user, NULL);
if (retval == PAM_SUCCESS) {
/*
* Various libraries at various times have had bugs related to
* '+' or '-' as the first character of a username. Don't take
* any chances here. Require that the username starts with a
* letter.
*/
if (!user || !isalpha((int)(unsigned char)*user)) {
if (user && on(UNIX_AUDIT))
pam_syslog(pamh, LOG_ERR,
   "Bad username: %s", user);
else
pam_syslog(pamh, LOG_ERR, "Bad username");
user = "UNKNOWN USER";
retval = PAM_USER_UNKNOWN;
goto out_save_retval;
}
The CLI command useradd allows you to create a user with the first character a number but you then can't set a password on it because of the PAM restriction  .  

The GUI tool (userdrake) does not allow you to create such a user.

[djohnston]

When I dug around, I discovered that PAM doesn't like logins that start with a number anymore (I've used the same login across all my systems since SVR3 in 1989, and it started with a number).

User passwords beginning with a number or series of numbers are still working here.

[TerryN]

I thought we were talking about username rather than passwords 

[djohnston]

I thought we were talking about username rather than passwords 

Yeah, looking again, you're right. Guess it's this cold, or the cold medicine, or just me.

[TerryN]

Further info:

PCLinuxOS default install uses the Openwall tcb package (pam_tcb) for authentication.

From /etc/pam.d/system-auth

auth        sufficient    pam_tcb.so shadow nullok prefix=$2a$ count=8
...
account     sufficient    pam_tcb.so shadow
...
password    sufficient    pam_tcb.so use_authtok shadow write_to=shadow nullok prefix=$2a$ count=8
...
session     required      pam_tcb.so

However, there is another authentication module (pam_unix) from kernel.org which could be used for system authentication. The equivalent code in that module is slightly different:

Code: [Select]

/* get the user'name' */

        retval = pam_get_user(pamh, &name, NULL);
        if (retval == PAM_SUCCESS) {
                /*
                 * Various libraries at various times have had bugs related to
                 * '+' or '-' as the first character of a user name. Don't take
                 * any chances here. Require that the username starts with an
                 * alphanumeric character.
                 */
                if (name == NULL || !isalnum(*name)) {
                        _log_err(LOG_ERR, pamh, "bad username [%s]", name);
                        retval = PAM_USER_UNKNOWN;
                        AUTH_RETURN;

i.e. it does allow numerics at the start of a user name.

So maybe previously you were using pam_unix rather than pam_tcb.  If you really want to keep your username you could try changing the system-auth to use pam_unix (risky because I don't think it would have changed without a good reason).  Check the options that pam_unix accepts with "man pam_unix" as they are different and make sure you know how to boot into single user mode  

[rubentje1991]

I thought we were talking about username rather than passwords 

Yeah, looking again, you're right. Guess it's this cold, or the cold medicine, or just me.

OK, neglect my post; didn't interpreted it well too 

[lonnieb]

Thanks. Too bad it's hard coded (I actually was afraid of that). Seems an overreaction to the "username starting with a '+' or '-'" to totally restrict it to a letter - but I'm not a pam developer.

I checked my logs, the tcb package I have was installed in June, but it wasn't until I updated in late September that a pam update changed the system-auth file to use the pam_tcb module.

Yes, I've spent that long looking for a solution before asking here, since I ran into the same problem in Mandrake something like 2-3 years ago, and I just worked around it by changing my login while pointing to the same home directory. But when it hit PCLOS, I figured I'd better find the source of the change before I update something on my servers and my remote access scripts started blowing up.

At least now I know the source of the problem and can switch back to pam_unix, although I'll have to remember to do that after each pam update, since I'm sure it will keep changing the system-auth file. Now I can watch the updates to my servers for a similar update.

Thanks everyone.

Lonnie

[lonnieb]

One last general statement on this. While I have no qualms with the developers for deciding that a user account must begin with a letter, that sort of change should have been added to useradd to prevent new accounts from being created with a non-letter. It is completely "bad form" to make a change that upon update renders previously existing accounts as being "invalid". There is no way of determining the impact that sort of change can have in system environments that are outside the developers' control. In my case, it was one user account, but in other cases it could be 100s of accounts and man-hours affected.

Anyway.... issue solved since the source of the change was found.

Lonnie