View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0004318||unreal||ircd||public||2014-06-19 05:30||2014-07-05 14:09|
|Target Version||184.108.40.206||Fixed in Version||220.127.116.11|
|Summary||0004318: Identified users can not being recognized as identified|
|Description||Users who are identified with services that use accountnames instead of usermode 'r' are not being recognized as identified when dealing with +R/+M channels.|
Services being used are Anope 2.0.1
|Tags||No tags attached.|
|3rd party modules|
I am able to replicate.
Steps I used to replicate:
1) identify to services using account names in /whois
2) change nick to unregistered nick so mode is set -r
3) join new channel
4) set channel mode +M-o <mynick>
5) attempt to speak
Hmm this does happen, But I assume it will do because UnrealIRCd only checks against numeric  "is identified" as opposed to numeric  user is logged in as accountname
 Amiga600 is identified for this nick
 Amiga600 is logged in as Amiga600
(No 307 numeric, which is correct, as "A600" is not a services registered nickname)
 A600 is logged in as Amiga600
I would assume it could be made to check the accountname to see if thats valid before allowing the user in +R +M channels to join/speak respectively.
I also assume the accountname will follow you until you either logout of services or disconnect, so this would indeed be useful to add to unrealircd.
Very good point you brought up here Jobe :)
Strictly speaking, UnrealIRCd doesnt check WHOIS numeric replies at all. Internally UnrealIRCd stores a "flag" on the user when the user has user mode +r, and has a field associated with the user for account name.
The problem as it stands is that the latter isn't being checked for a non-empty value.
Updated issue to reflect the following:
- Priority is "Normal", as we reserve high priority issues for crashes, blocks, exploits, security, etc.
- I lowered the severity from major to minor, as this is simply dealing with how UnrealIRCd is checking a user's access against internally stored information. This bug was introduced when we added support for user accounts.
- I have confirmed the issue based on Jobe's findings.
- I think this should be targeted for the next release of UnrealIRCd (18.104.22.168), though I cannot guarantee it will be fixed in that version.
I have the following suggestions to remedy the issue until a fix can be released:
- If supported by Anope, use +r to ensure users are continuing to be properly evaluated by UnrealIRCd when it comes to registered vs. unregistered permissions.
- Keep an eye on this bug for a patch or a resolution that can be diff'd out of our repository to apply to your own UnrealIRCd installation.
For services who allow you to log in by account name but still allow you to use a different nick: when you're logged in you are now considered registered as far as channel mode +M (only registered users may speak and +R (only registered users may join) are concerned. Same for user mode +R (only allow private messages from registered users).
Tech: whenever services set SVID and it's not * and does not start with a number, then we consider this user to be 'logged in'. Whenever a user is set +r (s)he is also considered 'logged in'. This way it's compatible with both older and new services and doesn't introduce security issues with older services using servicetimestamp for nick tracking or other means.
This issue was reported by ShawnSmith (0004318).
How to apply the patch:
wget -O patch "http://hg.unrealircd.com/hg/unreal/raw-rev/e25a31250723" patch -p1 <patch make && make install
If it doesn't work, let me know. I tested it with anope 2.x and 1.x.
|2014-06-19 05:30||ShawnSmith||New Issue|
|2014-06-19 10:07||Jobe1986||Note Added: 0018200|
|2014-06-19 10:18||Amiga600||Note Added: 0018201|
|2014-06-19 10:22||Amiga600||Note Edited: 0018201||View Revisions|
|2014-06-20 21:27||Jobe1986||Note Added: 0018202|
|2014-06-21 04:45||Stealth||Note Added: 0018203|
|2014-06-21 04:45||Stealth||Priority||high => normal|
|2014-06-21 04:45||Stealth||Severity||major => minor|
|2014-06-21 04:45||Stealth||Status||new => confirmed|
|2014-06-21 04:45||Stealth||Target Version||=> 22.214.171.124|
|2014-07-05 14:09||syzop||Note Added: 0018206|
|2014-07-05 14:09||syzop||Status||confirmed => resolved|
|2014-07-05 14:09||syzop||Fixed in Version||=> 126.96.36.199|
|2014-07-05 14:09||syzop||Resolution||open => fixed|
|2014-07-05 14:09||syzop||Assigned To||=> syzop|