Allow numbers in usernames

[ja5087]

E7 wants a group account with a number in the username and I don't see why not.

[kpengboy]

You probably wouldn't want all digit usernames, since those could be confused with UIDs.

Also, are there any additional usernames that would need to be reserved if numbers suddenly become valid characters in usernames?

[ja5087]

I don't think we expose a UID anywhere at the OCF though, but it's fair that just to avoid the possibility in case we ever do to make the first character lowercase alphabetical. As far as I can tell we haven't done anything special that would require more reserved usernames either.

[ja5087]

I've changed it so you need to have the first letter be a lowercase character.

[PotatoParser]

Would this be valid since the regex selects 3-16 digits/lowercase nums?

[ja5087]

It's not valid because the validation logic comes from validate_username. You're right that the regex is lax and I don't really know how to feel about it. On the one hand Kerberos principals can be any printable ASCII so there is nothing stopping us from creating [email protected] for example, and the method's purpose is to extract that out.

[kpengboy]

Is the goal of the regex to handle any arbitrary Kerberos principal, or only those which correspond to valid usernames? I must point out that the regex as written won't match hypothetical Kerberos principals which are longer than 16 characters, have hyphens in them, or the like.

[ja5087]

That's fair. I think making it tighter and in line with what we allow will be better than in this weird state of not doing either.

[kpengboy]

Is the goal of the regex to handle any arbitrary Kerberos principal, or only those which correspond to valid usernames? I must point out that the regex as written won't match hypothetical Kerberos principals which are longer than 16 characters, have hyphens in them, or the like.

[kpengboy]

Here are some additional steps I thought of that may be needed:

• Do we want to reserve usernames like adm1n?
• We'd need to create /home/a/a0, /home/a/a1, ..., /home/z/z9.

[ja5087]

Here are some additional steps I thought of that may be needed:

* Do we want to reserve usernames like `adm1n`?

* We'd need to create `/home/a/a0`, `/home/a/a1`, ..., `/home/z/z9`.

Considering we don't reserve things like admin either and it's probably impossible to maintain a list of all things that sound important, this might be a wontfix. As for the second point, I think this is already ensured by

ocflib/ocflib/account/utils.py

Line 52 in 309680a

def home_dir(user):

and when I tested this function to create e7staff it worked fine.

[kpengboy]

We do reserve admin FWIW:

ocflib/ocflib/account/validators.py

Line 18 in 309680a

'admin',

.
But agree we can consider reserving such leetspeak usernames in a different change.

[ja5087]

Oh huh I stand corrected, thanks.

[ethanhs]

I think talking to @nikhiljha, we're a bit hesitant to merge this, as people could use numbers to make their usernames a bit more obfuscated, e.g. m1337ax or something. I think just typing out the numbers (.e.g 7 is seven) is what we have done in the past.

[axmmisaka]

iirc we do have requirements that username must somewhat match real name and it's automatically enforced somewhere - could possibly be useful to prevent somebody using "adm1n" (the one who exploit it must has a name like Adam Norton or something...)