View Issue Details

IDProjectCategoryView StatusLast Update
0002301unrealircdpublic2013-05-06 06:06
Reportervonitsanet Assigned Tonenolod 
Status resolvedResolutionfixed 
Product Version3.2.3 
Target Version3.3-alpha0Fixed in Version3.4-alpha1 
Summary0002301: "NickName is an IRC Operator" field on whois
DescriptionCan be added On the whois information (for ircops only of course) something like this:

Normal Users Can See On Whois: NickName is an IRC Operator

IrcOps will see: NickName is an IRC Operator [Oper-Username]

Something like when an ircop Oper Up.
The server notice shows the oper username.

This is useful for all opers because they can who is the ircop even if he has changed his nick to something else.
TagsNo tags attached.
3rd party modules



2005-01-27 07:27

reporter   ~0008932

Good Morning:-PP
Any reply?:-)))


2005-01-27 22:10

reporter   ~0008933

um why? are ur ircops not all in the same channel?


2005-01-28 19:33

reporter   ~0008934

Actually I can see one use for this - if an oline got hacked and you the server admin are trying to figure out which one it is so as to delete it... and didn't catch the operup notice :) .


2005-01-29 00:06

reporter   ~0008935

aquanight log files?


2005-01-29 06:46

reporter   ~0008936

When someone is an ircop with a different nick and i can't think who is he and i haven't see the operup notice..
It's not so easy to /stats o and search the hostnames and check the olines or to login to my account to see the ircd logfile..

I ask for this feature so every ircop can check more easy who is who when he can't remember a nickname...


2005-01-29 11:18

reporter   ~0008937

in order tostop this person using this "hacked" opers line, you need to access ur shell and change the password for that oper, since ur already IN the shell why not check the log file?

what if a oper pastes another opers whois by accident into a userwhisper or user channel, youve given away that nicknames oper up name , thats why i dont see this as such a good idea.


2005-01-29 12:57

reporter   ~0008940

If you're smart, you shouldn't be able to hack an oline to begin with. It should require almost an exact host, and a decently strong password which is stored encrypted, or even better, an SSL key.

In any case, Unreal does not store the oper username with the user. Once the user is opered up, Unreal no longer keeps track of which oline they used. Therefore, adding this feature would increase memory usage since we'd now need to store this information. For something with limited utility (seeing as how the log already has this information) I'm not sure I'm willing to waste this memory usage.

Also, I don't quite agree with any of the reasons provided. As I said, oline hacking should be rare or impossible. I've never seen it occur and I've been an oper on about 10 different networks over a 6 year period. Second, when it does occur, you're going to need to go into the shell anyway. Then for the, finding out who an oper really is, well ever heard of /msg? "/msg SomeOperIDontKnow Hey, who are you?" Additionally, each server should not have more than 3-4 opers. So is doing a /stats o and comparing 3 hostmasks really that difficult? Seems like it would take half a second to me. So I don't see that as being useful either.


2005-01-29 18:39

reporter   ~0008955

[quote]In any case, Unreal does not store the oper username with the user. Once the user is opered up, Unreal no longer keeps track of which oline they used. Therefore, adding this feature would increase memory usage since we'd now need to store this information. For something with limited utility (seeing as how the log already has this information) I'm not sure I'm willing to waste this memory usage.[/quote]

Yet, AngryWolf's m_getinfo module is somehow able to retrieve information that you say is not stored?


2005-01-29 19:35

reporter   ~0008956

Also, if oper-up info is not stored, how does oper::maxlogins work?


2005-01-29 19:50

reporter   ~0008957

The two aren't related at all. Having int login_attempts; is different than having char *login_id;


2005-01-30 12:08

reporter   ~0008961

Last edited: 2005-01-30 12:11

I found this in AngryWolf's getinfo module...

        if (acptr->user->operlogin)
            sendto_one(sptr, ":%s 339 %s :Last used oper login: %s",
      , sptr->name, acptr->user->operlogin);

I somehow doubt that 'operlogin' field was something he made up :P .

Also, about the whole hostmask thing, well typically one relies more heavily on password security, and also, when dynamic IPs are involved, it's difficult to have an exact IP and username... Me for example, even though my IP has only changed about 3 times in the past year or so, the fact that it can change proves that I'm technically on a dynamic IP even if it pretty much only changes once in a blue moon...

Anyway, I suppose it's correct that this really isn't that useful. One can always check logs (unless they don't keep logs for some reason (shell limits?)) and the hostmask thing codemastr mentioned (even though that doesn't 100% work when an oper could match up with more than one hostmask... like when you have two opers from the same ISP and said ISP is super-dynamic (like, dialup dynamic :p))... *shrug*

*edit* Oh, a couple of other problems:
- This pretty much breaks when an oper gets oper privileges from services (SVS2MODE +o \ SVSO +O+etc).
- Looking at AngryWolf's use of it tells me that field is still valid when the oper deopers. And if said oper gets oper privileges from services, now you're displaying incorrect information...


2005-01-30 14:16

reporter   ~0008962

Hmm, yeah, I forgot, that was implemented by storing the login name. In any case though, I'm still not sure this is really worth adding. If people want it, I suppose it can be done, but it just seems like something no one will ever use and that will confuse most people.


2005-01-31 12:28

reporter   ~0008965

I've asking for this as a way to check more easy who is using an oline.
Yes there are many others way i agree and i'm sure it's useless for anything else.
Also this may be added with a snomask.
So opers will have a choice if the want to see this info or not.



2005-02-23 12:02

reporter   ~0009265

I would vote for putting the time it will take to do on something else, or bugs.


2005-02-24 23:32

reporter   ~0009290

Snomas...k?! ANOTHER one?!
Aaargh. Please god, no.


2005-03-08 06:32

reporter   ~0009507

Any final answer for this (little:P) feature?
It will be added sometime or not at all? :))


2005-03-08 09:18

reporter   ~0009513

wots wrong with adding this to a pre existsing snomask?


2005-03-08 09:38

reporter   ~0009516

You all seem to have forgotten the purposes of SNomasks. So I'll refresh you a little.

SNoMasks, standing for Server Notice masks, is a feature added to unreal to replace the generic +s usermode that was defined in the RFC (ie: what users got sent server notices, such as users connecting.) Now, this was really necessary since the number of server notices got BIGGER. And big networks got a LOT of snotices.

Now, you'll see here, that server notices are NOT pieces of information that a user can see. As you'll recall with the usermode conversation, there is a finite limit on the number of snomasks that can be used (32 again, I believe).

Now, can you imagine, if I added a snomask for each and every piece of optional information, how many there would be? A bloody lot.

[admittedly, some things like eyes snomask kind of go against this but.. oh well, another day, another feature request.]


2005-03-10 08:39

reporter   ~0009555

We can just not use any snomask/usermode.
This can be added to the /whois to all opers.
And if you want to disable it do it from config?


2005-03-21 08:36

reporter   ~0009640

ok heres an addition that accord in the #unreal-support room
08:15 <+Dj-Neo> Your maximum number of concurrent oper logins has been reached (2)
08:16 <+Dj-Neo> I can't !
08:16 <+Dj-Neo> I can't oper me
Now say he is competant and has a fellow staff memeber around, they can do a who +m o and see who is opered then do a simple whois on each to see who is using this guys oline


2005-03-21 10:29

reporter   ~0009641

Anyway can we do something about this thing?:P


2005-11-12 10:47

reporter   ~0010724

i have seen this somewhere (modulized).
bt i dont remember the ircnetwork:(


2007-04-18 19:02

reporter   ~0013551

This looks like a good feature to me. I'll add it if no one else wants to take a swing at it.

2007-04-19 22:49


m_whois.patch (947 bytes)


2007-04-19 22:50

reporter   ~0013614

Last edited: 2007-04-19 23:00

Potential patch uploaded. m_whois.correct.patch. (Ignore the other =P)

2007-04-19 22:59



2007-04-24 05:31

reporter   ~0013654

Fixed in .2371


2011-07-19 14:18

administrator   ~0016706

needs re-porting, or did we already add this?


2013-02-26 06:54

reporter   ~0017442

I say no thanks.

There isnt a practical reason the expose an opers login to other opers. Admins just need to secure their oper's olines, simple as that. Yes, it is a pain in the butt to add 50 hostmasks but no one says being an admin is fun 24/7.

At best i can see an admin using this info for their locally connected opers, but not global as they likely have no shell access to fix any problems anyway.


2013-02-27 14:14

reporter   ~0017443

Last edited: 2013-02-27 14:29

View 9 revisions

You have serious issues with your opers don't you?
Do you also suspect any of your opers for DoS attacks by explosing your hub's IP perhaps?

---"Admins just need to secure their oper's olines, simple as that."
You said it, not me.

---"Yes, it is a pain in the butt to add 50 hostmasks"
There is no reason to add anything than *@* for a single oper:

---"but not global as they likely have no shell access to fix any problems anyway."
Says who? For your setup maybe. For other's maybe not.


2013-02-27 23:30

reporter   ~0017444

1> Not all clients support SSL certs so the point of *not* using *@* is still highly relevant.

2> Securing oper blocks as strictly as possible has been standard practice by experienced admins that have eye witnessed rogue opers for nearly 20 years now, it's not my invention. There is a reason we check a hostmask to start with.

3> Please allow me to quote RFC1459, dated May 1993. Section 8.12.2:

 "The granting of operator privileges to a disruptive person can have
   dire consequences for the well-being of the IRC net in general due to
   the powers given to them. Thus, the acquisition of such powers
   should not be very easy."

SSL Certs aside, using strict hostmasks, max logins, requiring certain usermodes like +z is how UnrealIRCd helps admins secure oper blocks. So I say again, Admins need to secure their oper blocks .. it's as simple as that.

Anyway, back on topic. To help keep the network secure, I don't advise broadcasting any portion of an opers login information, even to opers.


2013-02-28 00:50

reporter   ~0017445

Last edited: 2013-02-28 01:01

View 3 revisions

All major clients support SSL and as we are talking about opers, you may want to advice (or force) them to use such a client (or their own client through ssl tunnel).

Also, back in 1993 we had not such features like SSL authentication.

Besides that, as '/stats o server' returns the operblock list, I can't see any difference in terms of security.


2013-02-28 01:04

reporter   ~0017446

There is a difference between using ssl to connect to irc and using ssl certs as a password, the latter is what you referred in defense of using *@*.

My underlying point is that if you secure your oper blocks properly like any good admin will, then you won't have a need to see whom is using what login in the first place, you will already know. Lets not forget about our logfiles. Granted, no everyone has log file access. That only reinforces my point about broadcasting oper login info to those that don't need it because they can't do anything about it anyway. It also reinforces my previous statement that at best, only the local admin would have any use for it.

As far as whom has shell access or may need this on your individual network, there is a patch attached to assist you.


2013-02-28 01:07

reporter   ~0017447

To use SSL as a password you need to connect through SSL and use your own certificate.


2013-02-28 01:09

reporter   ~0017448

"To use SSL as a password you need to connect through SSL and use your own certificate."

Obviously, but still not all clients support the SSL Cert as a password portion of your statement and stunnel will not fix that.

Lets stay on topic now please.


2013-02-28 01:19

reporter   ~0017449

Inside stunnel configuration i can see the following section:

# Certificate Authority file
CAfile = ca-chain.pem
# Your client certificate in PEM format.
cert = mycert.pem
# Where the private key is kept.
key = mycert.pem

So I can't see why stunnel will not fix that. Did I miss something here?


2013-02-28 01:29

reporter   ~0017450

Last edited: 2013-02-28 01:33

View 2 revisions

Even if you are correct, it's still off topic. Not to mention that as an IRCd we can't expect every admin in the world to force SSL on their opers. We have to focus on security for anyone that uses Unreal, not just a few networks that so choose to force ssl.

This feature is about broadcasting oper login information to other opers. Something that I see as pointless and as a security risk because it's easier to accidentally paste the /whois output than the /stats o output to the public. JoeOper from RandomServ1 doesn't need access to JonnyAdmin's oper login from RandomServ2.

I say again, there is a patch attached that should help your individual network.

Good Day.


2013-02-28 02:09

reporter   ~0017451

After thinking about what I truly object here, it's more of how easy it would be to accidentally paste /whois than opers knowing others logins, while I still disagree that opers need to know, i'm more troubled about this being in the /whois. I'm always paranoid when there is oper only information available in regular user commands. Silly? Perhaps, but not unwarranted.

Obviously, if this goes in, please make it optional.

vonitsanet, in addition to the attached patch, you may want to consider the GETINFO module. It's like a /whois on steroids and will tell you what oper login was used. Personally, I'd like to see the GETINFO module part of Unreal's core.


2013-02-28 04:19

reporter   ~0017452

Please keep this on topic.

I am tired of seeing you two bicker in my inbox with this issue. If you would like to discuss the relationships of SSL connections and SSL authentication and how it applies to opers, PLEASE DO SO SOMEWHERE ELSE.

Any further off-topic notes will be deleted.

Syzop has already marked this for re-porting, there is no need to continue to discuss this issue. If it is added to 3.3 and you want it, great; if not, don't use it.


2013-02-28 04:37

reporter   ~0017453

Now, back on topic:

The requested feature simplifies the ability to identify an oper if the oper has changed his/her nick.

> There isnt a practical reason the expose an opers login to other opers.

Oper logins can be viewed by other opers in the oper-up notice announcing a login. The oper login can also be seen with /stats o, then matched to the oper matching the userhost. An oper can also find track nickchanges from that original oper notice using snomasks nN.


2013-03-02 00:24

reporter   ~0017454

Uhm, no Stealth.

1> The patch attached is *not* optional so I can't simply "not use it".

2> All of the instances where the oper login is already seen is true enough but none of them are executed using a user command, like /whois.

/stats o - oper only by default.
oper up notice - oper only.
snomask nN - oper only.
/whois - a very basic *USER* command.

Utter chaos has been wrought from users gaining access to oper information by 1 form or another. Granted, it's also been coupled with the network security level set on stupid, but still. UnderNet was nearly brought to it's knees because a user social engineered oper information. We as opers are more likely to expose sensitive information to users from the output of user commands than we are from oper only commands. It's a mental thing, but still happens.

We have the option for opers to invite themselves into +ps channels .. why? that is to prevent an oper from accidentally joining such channels be way of a normal user command, which is done out of habit and by placing the oper login into the /whois output we are creating the exact same possibility of accidentally exposing otherwise sensitive data to users. Am I the only one that sees that?!

If you want a /whois style way of showing sensitive info to opers, then adopt GETINFO into Unreal's core or ship it with Unreal as a module exactly like already is. It takes 5 minutes .. hell, I'll even do the patch for it!


2013-03-02 18:47

administrator   ~0017455

39 comments.. woah.

As Stealth noted (and myself), the idea is accepted and needs to be re-ported.

I also disagree that exposing oper login information to other IRCOps is a problem.

In fact, I don't see a reason to make this configurable... I find this rather ridiculous.. but if the person who writes the patch has too much time on his/her hands then sure.. why not.. I'm not going to block it either.


2013-03-03 01:40

reporter   ~0017460

In reply to katsklaw about including the info in a basic user command, please read the patch before you make even more of a fool of yourself:

+ if (IsOper(sptr) && MyClient(acptr))
+ sendto_one(sptr,
+ ":%s 313 %s %s :is %s (%s)",
+, parv[0],
+ name, buf,
+ acptr->user->operlogin);

The oper login is only displayed if the user requesting the whois is an oper, so therefore it is not and will not be provided to users.


2013-05-06 06:05

reporter   ~0017486

Issue History

Date Modified Username Field Change
2005-01-25 06:02 vonitsanet New Issue
2005-01-27 07:27 vonitsanet Note Added: 0008932
2005-01-27 22:10 White_Magic Note Added: 0008933
2005-01-28 19:33 aquanight Note Added: 0008934
2005-01-29 00:06 White_Magic Note Added: 0008935
2005-01-29 06:46 vonitsanet Note Added: 0008936
2005-01-29 11:18 White_Magic Note Added: 0008937
2005-01-29 12:57 codemastr Note Added: 0008940
2005-01-29 18:39 aquanight Note Added: 0008955
2005-01-29 19:35 Stealth Note Added: 0008956
2005-01-29 19:50 codemastr Note Added: 0008957
2005-01-30 12:08 aquanight Note Added: 0008961
2005-01-30 12:11 aquanight Note Edited: 0008961
2005-01-30 14:16 codemastr Note Added: 0008962
2005-01-31 12:28 vonitsanet Note Added: 0008965
2005-02-23 12:02 devil Note Added: 0009265
2005-02-24 23:32 w00t Note Added: 0009290
2005-03-08 06:32 vonitsanet Note Added: 0009507
2005-03-08 09:18 White_Magic Note Added: 0009513
2005-03-08 09:38 w00t Note Added: 0009516
2005-03-10 08:39 vonitsanet Note Added: 0009555
2005-03-21 08:36 RandomNumber Note Added: 0009640
2005-03-21 10:29 vonitsanet Note Added: 0009641
2005-11-12 10:47 vonitsanet Note Added: 0010724
2007-04-18 19:02 WolfSage Note Added: 0013551
2007-04-19 02:27 stskeeps Status new => acknowledged
2007-04-19 22:49 WolfSage File Added: m_whois.patch
2007-04-19 22:50 WolfSage Note Added: 0013614
2007-04-19 22:54 WolfSage Note Edited: 0013614
2007-04-19 22:59 WolfSage File Added: m_whois.correct.patch
2007-04-19 23:00 WolfSage Note Edited: 0013614
2007-04-20 03:21 stskeeps Status acknowledged => confirmed
2007-04-24 05:31 stskeeps Status confirmed => resolved
2007-04-24 05:31 stskeeps Fixed in Version => 3.3-alpha0
2007-04-24 05:31 stskeeps Resolution open => fixed
2007-04-24 05:31 stskeeps Assigned To => stskeeps
2007-04-24 05:31 stskeeps Note Added: 0013654
2011-07-19 14:18 syzop Note Added: 0016706
2011-07-19 14:18 syzop Assigned To stskeeps =>
2011-07-19 14:18 syzop Status resolved => needs re porting
2011-07-19 17:11 syzop Target Version => 3.3-alpha0
2013-02-12 06:56 dummy Status needs re porting => has patch
2013-02-19 22:54 syzop Status has patch => needs re porting
2013-02-26 06:54 katsklaw Note Added: 0017442
2013-02-27 14:14 vonitsanet Note Added: 0017443
2013-02-27 14:18 vonitsanet Note Edited: 0017443 View Revisions
2013-02-27 14:20 vonitsanet Note Edited: 0017443 View Revisions
2013-02-27 14:20 vonitsanet Note Edited: 0017443 View Revisions
2013-02-27 14:22 vonitsanet Note Edited: 0017443 View Revisions
2013-02-27 14:27 vonitsanet Note Edited: 0017443 View Revisions
2013-02-27 14:28 vonitsanet Note Edited: 0017443 View Revisions
2013-02-27 14:28 vonitsanet Note Edited: 0017443 View Revisions
2013-02-27 14:29 vonitsanet Note Edited: 0017443 View Revisions
2013-02-27 23:30 katsklaw Note Added: 0017444
2013-02-28 00:50 vonitsanet Note Added: 0017445
2013-02-28 00:51 vonitsanet Note Edited: 0017445 View Revisions
2013-02-28 01:01 vonitsanet Note Edited: 0017445 View Revisions
2013-02-28 01:04 katsklaw Note Added: 0017446
2013-02-28 01:07 vonitsanet Note Added: 0017447
2013-02-28 01:09 katsklaw Note Added: 0017448
2013-02-28 01:19 vonitsanet Note Added: 0017449
2013-02-28 01:29 katsklaw Note Added: 0017450
2013-02-28 01:33 katsklaw Note Edited: 0017450 View Revisions
2013-02-28 02:09 katsklaw Note Added: 0017451
2013-02-28 04:19 Stealth Note Added: 0017452
2013-02-28 04:37 Stealth Note Added: 0017453
2013-03-02 00:24 katsklaw Note Added: 0017454
2013-03-02 18:47 syzop Note Added: 0017455
2013-03-03 01:40 Stealth Note Added: 0017460
2013-05-06 06:05 nenolod Note Added: 0017486
2013-05-06 06:05 nenolod Status needs re porting => resolved
2013-05-06 06:05 nenolod Fixed in Version 3.3-alpha0 => 3.4-alpha1
2013-05-06 06:05 nenolod Assigned To => nenolod