From Bugzilla Helper: User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1.1.4322) Description of problem: I have seen the patch for shadow-utils to fix the punctuation problem when entering users in the console, and it worked fine. However, for some reason, when trying to add or edit a user whose name contains some sort of punctuation (user.name) it bring an error and doesn't allow any change to be made, or the new user to be added. Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: 1.open gnome useradd program 2.enter user.name 3.click ok Actual Results: error appears disallowing user because name included invalid character Expected Results: user should have been entered, without problem. Additional info:
the newest useradd (part of shadow-utils) does allow some punctuation (underscore, period, dash (but not as the first char), and dollar sign (only as the last char; use discouraged; for samba interoperability) e-regex syntax is: [A-Za-z0-9_.][A-Za-z0-9_.-]{0,15} (This is what POSIX recommends for user/group names) the gnome-useradd (assuming you mean system-config-users) uses a different validator. changing component.
Maybe an update has been made since the last time I tried using system-config-users (it was about 2 months ago), but the validator for this program also does not allow a '.' in the name. Has a patch been made to fix this problem?
Adrian, the code in s-c-users checks for length <= 32 chars, while your regex only allows for up to 16 chars. Do you know what actually is the max length for Linux user names?
comment 3: should be length <= sizeof(ut.ut_user)... which is (currently) 16 chars. See bug 56850
Miloslav: I'll hard code 31 chars max for now (which breaks strings BTW, therefore only in CVS first), then I'll bump this one to you to implement libuser giving me that info, when you're ready bump it back to me so I can remove the hardcoded things, ok?
Adrian, current s-c-users code checks that user/group names don't have a digit as their first character, probably to avoid things like user "123" having uid "321" ;-). I guess I'll leave that enforcement in place, it's sensible IMO. What do you think?
Hmm, maybe enforcing one alpha character minimum would be better. Opinions?
comment 7,8: i certainly can see where one would want at least one alpha character or the first character be non-numeric. However, posix is pretty clear that all numeric user and group names are ok-- and useradd/etc don't seem to have a problem with number-only user/group names.
(In reply to comment #9) > However, posix is pretty clear > that all numeric user and group names are ok-- and useradd/etc don't seem to > have a problem with number-only user/group names. They are nevertheless very impractical --- if the name is all-numeric and there exists an user/group with that number, the string is interpreted as a numeric ID, not a string. This means that things like (chgrp $(id -gn)) stop working. They are not quite portable, but I wouldn't think of the all-numeric possibility when writing a script (without participating in this discussion, at least). I'd suggest at least a warning for all-numeric names. Enforcing a restriction not enforced by useradd seems to be a recipe for a "remove the restriction" bug (:
libuser.UT_NAMESIZE is available from Python since libuser-0.53.1.
This is great. I think I'll still harass the user for choosing all numeric user names or other stuff ("If you want to shoot yourself in the foot, you can still use command line tools" ;-).
from comment #1: useradd... does allow some punctuation (underscore, period, dash (but not as the first char), and dollar sign (only as the last char; use discouraged; for samba interoperability) this is correct, a username with a trailing $ can be created, however, the account cannot be edited in system-config-users (except that a name change can be forced based on user input, that doesn't allow the $), nor can an account with trailing $ be created. As suggested above, a fix for both situations within s-c-u would help samba interoperability. or should I submit a new bug ...?
"Samba interoperability" means, as far as I know, machine accounts. There's not much you can reasonably do with such accounts (considering the extra data samba stores), maybe except for deleting them.
Fedora Core 2 is now maintained by the Fedora Legacy project for security updates only. If this problem is a security issue, please reopen and reassign to the Fedora Legacy product. If it is not a security issue and hasn't been resolved in the current FC3 updates or in the FC4 test release, reopen and change the version to match.
This problem is still present.
I've fixed this in s-c-users CVS. Adrian, s-c-users should now behave as useradd/groupadd concerning the validity of user names/group names -- with one exception: I don't allow a trailing "$" in group names because AFAIK only user names get abused that way by Samba -- is that assumption correct?
(In reply to comment #18) > I've fixed this in s-c-users CVS. > > Adrian, s-c-users should now behave as useradd/groupadd concerning the validity > of user names/group names -- with one exception: I don't allow a trailing "$" in > group names because AFAIK only user names get abused that way by Samba -- is > that assumption correct? Correct, the allowing of the '$' is only for internal Samba user, so s-c-users need not allow it.
Fixed in system-config-users-1.2.39-1.
From User-Agent: XML-RPC system-config-users-1.2.39-0.fc4.1 has been pushed for FC4, which should resolve this issue. If these problems are still present in this version, then please make note of it in this bug report.