| Summary: | [net-misc/openssh=4.3_p2] breaks w/ slashes in usernames | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Enrico 'nekrad' Weigelt <weigelt> |
| Component: | Current packages | Assignee: | Gentoo Linux bug wranglers <bug-wranglers> |
| Status: | VERIFIED INVALID | ||
| Severity: | normal | CC: | beu, sgtphou, spb, thedude0001 |
| Priority: | High | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | gentoo patch openssh_4.3_p2.selinux.patch introduces the fault. fixed version attached. | ||
| Package list: | Runtime testing required: | --- | |
| Attachments: |
fixed version of openssh-4.3_p2-selinux.patch
openssh-4.3_p2-selinux-metux.patch |
||
|
Description
Enrico 'nekrad' Weigelt
2006-09-14 13:20:16 UTC
man useradd <snip> Usernames must begin with a lower case letter or an underscore, and only lower case letters, underscores, dashes, and dollar signs may follow. In regular expression terms: [a-z_][a-z0-9_-]*[$] </snip> I've now tracked it down: It is an gentoo patch, which explicitly custs off the username at an '/'. But I didn't find out yet where this patch actually comes from - emerge -f doesn't seem to download it. Your username is illegal, period. It worked for almost ten years now. In fact several hundreds of them now worked for almost ten years. And it still works on non-gentoo systems. It is an gentoo-specific problem. Now could you please help me in fixing this ? Where does the patch actually come from ? # useradd ab/cd useradd: invalid user name 'ab/cd' Yes, gentoo's usedadd also refuses slashes, so I had to take it from another (non-gentoo) system. Evrything else works properly. I still dont see, why an gentoo-specific patch explicitly breaks usernames with slashes. Any *good* explaination, why this is *necessary* ? Kindly read the above manpage. Enrico, You keep insisting that a Gentoo-provided patch results in this behaviour (the disallowing of '\' in a login name); please either show us this patch, or shut up. And I'm pretty sure you won't be able to as no patches are applied to sys-apps/shadow that explicitly disallow this. Therefore, this is an upstream problem - go pester them. Thanks, There's no Gentoo-specific patch that forbids the retarded / character in username. Go unpack vanilla sys-apps/shadow tarball from distfiles and read the code. Especially read libmisc/chkname.c
<snip>
static int good_name (const char *name)
{
/*
* User/group names must match [a-z_][a-z0-9_-]*[$]
*/
if (!*name || !((*name >= 'a' && *name <= 'z') || *name == '_'))
return 0;
while (*++name) {
if (!((*name >= 'a' && *name <= 'z') ||
(*name >= '0' && *name <= '9') ||
*name == '_' || *name == '-' ||
(*name == '$' && *(name + 1) == '\0')))
return 0;
}
return 1;
}
This bug is plain invalid, / is NOT a legal character in username on Gentoo, it isn't on Fedora and it isn't on Ubuntu, and I won't waste more time checking others... Besides, common sense suggests more than a bunch of pretty obvious reasons why it isn't a valid character.
Nothing to fix here beyond your broken usernames, closing.
(In reply to comment #8) > You keep insisting that a Gentoo-provided patch results in this behaviour (the > disallowing of '\' in a login name); please either show us this patch, or shut up. It breaks on '/' not '\'. See: openssh_4.3_p2.selinux.patch:54 openssh_4.3_p2.selinux.patch:85 > And I'm pretty sure you won't be able to as no patches are applied to > sys-apps/shadow that explicitly disallow this. Therefore, this is > an upstream problem - go pester them. I'm not interested in shadown, but openssh at this point. Damn read the code above! It's NOT a legal character, \ isn't and / isn't, [a-z_][a-z0-9_-]*[$] is. Stop bugspamming us. Closed. WHO defines what's a legal username for openssh ? The openssh upstream does _NOT_ forbid it. As I already pointed out, it is the gentoo patch, which introduces the fault. I'm still awaiting an good explaination, why gentoo breaks with the upstream here. There's nothing broken here except for your usernames. There's no way to create such broken usernames except for using a homebrew broken useradd. If you are using broken homebrew useradd to create broken invalid usernames, then go "fix" openssh to honor such invalid usernames yourself, as you did with useradd. It's non-issue for anyone using valid usernames, nothing to be fixed here. We're talking about sshd, not useradd. Maybe useadd refuses slashes, but why then should openssh explicitly break with them ? _ALL_ other tools work properly with slashes in usernames, and you *still* did not tell me any reason, why it should be forbidden. Gentoo always claims to be as near to the upstream as possible. The vanilla openssh does not break with slashes - this behaviour is explicitly introduced by gentoo. Why ?! Sure, just that openssh authenticates against user accounts, which are broken on your box because they contain illegal characters. CLOSED, stop reopening this bug. We won't support your broken useradd that's not distributed by us. WHO defines what's a legal username for openssh ? The openssh upstream does _NOT_ forbid it. As I already pointed out, it is the gentoo patch, which introduces the fault. I'm still awaiting an good explaination, why gentoo breaks with the upstream here. Created attachment 97019 [details, diff]
fixed version of openssh-4.3_p2-selinux.patch
simply removed the explicit cutting of the username on / in auth1.c and auth2.c
Feel free to remove it in your overlay. If you still didn't grok that openssh uses system accounts to verify users and that your accounts are not valid, there's no hope for you, sorry. Obviously there's no interest @ gentoo in fixing this. Interesting, that there's only *one* person always declaring this issue invalid and argumenting with an some completely different package, which has absolutely nothing to do with openssh. The other one, asking for an patch, got it. So I'm going back to the upstream. It is working properly, as it already did for years. @ Jakub: If you're too ignorant to event listen to my concern, also ignore the fact that it's the gentoo patch, which explicitly introduces this breakage, and just answer with invalid arguments instead explaining the NEED for that hard intervention (again: this is NOT done by the upstream !), then just become happy with your arrogance. I don't intend to bother you anlonger. Someone who's not even willing to listen, isn't worth spending any further minute with. My part is done. I supplied an patch, so others, having the same problem, can find it. Perhaps you would have more success if you provided a fixed patch which did not remove the feature that the patch was supposed to add in the first place. Jabkub, why the hell are you deleting my patches ?! I suspect, if you could, you probably would also delete my comments, since evrything I say is, per definition, invalid. (In reply to comment #22) > Perhaps you would have more success if you provided a fixed patch which did not > remove the feature that the patch was supposed to add in the first place. Aehm, what feature ? Destroying unliked usernames is an feature ? Why ? (In reply to comment #23) > Jabkub, why the hell are you deleting my patches ?! > > I suspect, if you could, you probably would also delete my comments, since > evrything I say is, per definition, invalid. He didn't delete it. It's still accessable. He just marked it obsolete because breaking another functionality is not acceptable. Nothing wrong with that, really. You broke selinux with your "fix". Do some research before messing with selinux stuff, in particular with user/role things. (In reply to comment #26) > You broke selinux with your "fix". Do some research before messing with selinux > stuff, in particular with user/role things. > Exactly ? (In reply to comment #27) > Exactly ? Exactly don't blindly delete parts of patches that are there for a reason. I'd just let this bug dead and burried, but since you are claiming that Gentoo developers are stupid (http://oss-qm.metux.de/index.php/Comment/nekrad/Stupid_gentoo_folks) I can't resist. Dear Enrico, kindly review IEEE Std 1003.1-2001 (Single UNIX Specification V3) - http://www.unix.org/single_unix_specification/ <quote> 3.426 User Name A string that is used to identify a user; see also User Database. To be portable across systems conforming to IEEE Std 1003.1-2001, the value is composed of characters from the portable filename character set. The hyphen should not be used as the first character of a portable user name. 3.276 Portable Filename Character Set The set of characters from which portable filenames are constructed. A B C D E F G H I J K L M N O P Q R S T U V W X Y Z a b c d e f g h i j k l m n o p q r s t u v w x y z 0 1 2 3 4 5 6 7 8 9 . _ - The last three characters are the period, underscore, and hyphen characters, respectively. </quote> So, before you start to rant next time, I'd suggest doing some legwork and research instead of publically claiming that someone is stupid; otherwise you risk making an idiot out of yourself. :P (In reply to comment #29) > otherwise you > risk making an idiot out of yourself. :P Be realistic, there's not much to loose. The other thing you seem to be missing here is that the patch does not break at / merely because it can, but does so in order to add functionality that some users require, without breaking compliance with any known standards for valid usernames. That, not any sort of stubbornness, is the reason why the behaviour is not going to change. (In reply to comment #29) > I'd just let this bug dead and burried, but since you are claiming that Gentoo > developers are stupid > (http://oss-qm.metux.de/index.php/Comment/nekrad/Stupid_gentoo_folks) I can't > resist. Ah, it worked. Seems, you just need some provocation as motivation ? ;-o > Dear Enrico, kindly review IEEE Std 1003.1-2001 (Single UNIX Specification V3) > - http://www.unix.org/single_unix_specification/ <snip> Okay, it does not explicitly allow an / in usernames - if the username shall be portable. But I couldn't find anything that *forbids* the / - it's just not portable (as conforming to the standard). BTW: at least on Linux, filenames *may* contain slashes (as well as spaces, etc). Just checked that. Of course they have to be escaped, if you want to access those files. Still you didn't say, why it's necessary to cut off the username at an /. As it is in the selinux patch, I just can assume, that is has something to do with selinux. But then, why isn't that code in some proper #ifdef ? I really wonder why you just don't tell me the reason. Looks like you don't even know it. Since, from my reading of the patch, the / is used to seperate user and role, the functionality is needed on any ssh client that is used to login to an selinux-enabled sshd. It makes no sense to wrap it in #ifdef. (In reply to comment #31) > The other thing you seem to be missing here is that the patch does not break at > / merely because it can, but does so in order to add functionality that some > users require, without breaking compliance with any known standards for valid usernames. Maybe. But *WHAT* is this exactly for ? It's introduced by gentoo, not the upstream, and its done only in some versions. There's no comment which tells what it is for. I only reason I could imagine is that selinux (ab)uses the / for somehing else, so its something selinux specific stuff. But why isn't it only built-in when selinux is really enabled ? (In reply to comment #33) > Since, from my reading of the patch, the / is used to seperate user and role, > the functionality is needed on any ssh client that is used to login to an > selinux-enabled sshd. It makes no sense to wrap it in #ifdef. I think it makes sense if the sshd is _NOT_ selinux-enabled. When building w/ -selinux, why should there any selinux stuff ? Does this make sense ? BTW: after deeper crawling in bgo, I learned that this patch probably was taken straight from Fedora. The changelog @ fedora looks interesting: turned selinux stuff on and off every few weeks ;-P I think that you miserably failed to provide a single valid reason for touching that patch, so unless you have one, stop producing noise on this bug. This is not a discussion forum. > I think it makes sense if the sshd is _NOT_ selinux-enabled.
>
> When building w/ -selinux, why should there any selinux stuff ? Does this make
> sense ?
Read what I said. It's needed when logging in to a remote server whose sshd is selinux-enabled. This has nothing to do with the state of selinux on the local system.
I found some posting that indicates, the role is separated by an ":" (BSD also uses this for specificying some "style" - maybe something similar to roles). http://www.nsa.gov/selinux/list-archive/0408/7999.cfm The patch seems to differenciate between roles and styles. Styles are already supported by the upstream (probably BSD specific) - roles are introduced by the selinux patch. What's the difference between styles and roles ? Created attachment 98256 [details, diff]
openssh-4.3_p2-selinux-metux.patch
Fixed the selinux patch to be do the whole selinux stuff only if building w/ selinux is actually enabled. (#ifdef WITH_SELINUX ...)
Comment on attachment 98256 [details, diff]
openssh-4.3_p2-selinux-metux.patch
This patch may have better chances to go into the upstream.
That is a no go since it requires selinux to be enabled, and hence all the libraries installed, on the client machine in order to specify roles when logging in to an selinux-enabled server. I guess you really need to re-read Comment #33 and Comment #37 couple more times. There's no way for the client to know whether the remote sshd server has selinux enabled or not, this can't be conditional on selinux being enabled on client. (In reply to comment #41) > That is a no go since it requires selinux to be enabled, and hence all the > libraries installed, on the client machine in order to specify roles when > logging in to an selinux-enabled server. Aehm, are we really talking about the same thing ? My changes are all in the _server_ code. Of course it's the _server_ who has to cope with selinux-specific stuff, In a selinux-situation it's the server who has to split off the username string (passed by the client) into local username and role, so it can pass it to the proper selinux functions (and of course it needs the selinux libs for that ;-P). But in an normal non-selinux situation, the whole stuff is really unnecessary. I don't see where the client needs any of the selinux libs for logging into an selinux-box. (the client may not be even be an linux). But, please correct me, if I'm wrong ... Enrico: Please stop spamming this bug. As a displinary measure, i will disable your account for one week. |
