View Issue Details

IDProjectCategoryView StatusLast Update
0003148unrealircdpublic2015-07-19 20:01
Reporteravb Assigned Tosyzop  
Status closedResolutionfixed 
OSAnyOS VersionAny 
Product Version3.2.6 
Fixed in Version3.4-beta1 
Summary0003148: Is local operator privileges should be reduced?
DescriptionWhy LocOps able to use such commands as /globops?

I mean, that globops is global messages (from services or other servers for example), so theoretically this must be available to global operators and so on, isn't it?
TagsNo tags attached.
3rd party modules



2006-12-17 01:40

reporter   ~0012833

btw, locops without "local" operflag (only get_host for example) - still able to set +g on themselves and receive globops, but unable to send globops


2006-12-18 10:03

reporter   ~0012842

Last edited: 2006-12-18 17:12

why you make someone ircop (local!) when you dont trust him to not even send/receive globops?


2006-12-18 19:22

reporter   ~0012848

Last edited: 2006-12-18 19:26

it is not possible to control all (local) ircops over the irc network, every server administrator can add locops on his server, so why they must be able receive globops if i not trust them? ;)

i mean, that actually i'm will not add them, but servers admins can


2006-12-19 05:33

reporter   ~0012849

Then the question needs to be asked why do you not trust your server admins to add users they trust as local opers?

At the end of the day anything regarding IRC oper priviledges tends to come back to trust.

As for local opers being able to send /globops, how else do they call for an oper with global permissions to take care of a nuisance user they cant deal with themselves?


2006-12-19 07:21

reporter   ~0012852

unfortunately all people not without weakness, some people think that ircop = god, that of cource can tell negative on irc network reputation if such people become ircops, exactly because of that i can't entrust global ircops for those who i don't know in person.

So if some server admin think that some other person must become local ircop - okay i will not prevent that, but i not want admit those people to get any global privileges.

P.S. Sorry, sometimes it is hard to me to tell in English exactly what i mean (think), so sometimes i can write some sort of tautology ;-)


2006-12-19 08:16

reporter   ~0012853

Last edited: 2006-12-19 08:18

I think that the argument about "trust" is completely lame and is not valid.
Theres no way to know who you can truly trust. Even your most trusted friends can do things you would never expect them to.

Take a network like efnet for example, how could you possibly really know if new opers can be trusted? Some people would try to link servers, just to get hub ips.. how could u possibly know that when u link them ? even if you do know them very well and for a long time ?

The argument about not having opers you don't trust is just stupid. Its not about trust, its about not knowing who you can trust in many cases.


2006-12-19 13:36

reporter   ~0012854

Last edited: 2006-12-19 13:36

okay, i'm try to say in other words:

what the difference between local ircop and global ircop (in general)?
both can connect/squit/rehash/restart/die servers, kill users, see some sensivite info, etc, etc...
but global opers can do those things on any server around the network, and local opers - only on "his" server, locally.

The general idea of local ircops (as i'm understand it) to restrict abilities only to some specific server, so why they can use global opers chat (that btw can contain some sensivite info - messages from services, etc)(/globops) and use some other "global" things?


2006-12-19 14:03

reporter   ~0012856

lol, i'm agreeing with you avb, i think localops should be more restricted.
Personally, i think that there should be a way for much better control over what irc ops of any level can see/do, without having to pay for a module to do it


2007-04-27 03:18

reporter   ~0013771

We should implement more flexible oper classes, like, classes defined in .conf or something.


2015-07-19 20:01

administrator   ~0018534

There's no locop anymore in 3.4-beta1 so... fixed.

Issue History

Date Modified Username Field Change
2006-12-17 01:37 avb New Issue
2006-12-17 01:40 avb Note Added: 0012833
2006-12-18 10:03 vonitsanet Note Added: 0012842
2006-12-18 17:12 vonitsanet Note Edited: 0012842
2006-12-18 19:22 avb Note Added: 0012848
2006-12-18 19:26 avb Note Edited: 0012848
2006-12-19 05:33 Jobe Note Added: 0012849
2006-12-19 07:21 avb Note Added: 0012852
2006-12-19 08:16 djGrrr Note Added: 0012853
2006-12-19 08:18 djGrrr Note Edited: 0012853
2006-12-19 13:36 avb Note Added: 0012854
2006-12-19 13:36 avb Note Edited: 0012854
2006-12-19 14:03 djGrrr Note Added: 0012856
2007-04-27 03:18 stskeeps Note Added: 0013771
2007-04-27 03:18 stskeeps Status new => acknowledged
2015-07-19 20:01 syzop Note Added: 0018534
2015-07-19 20:01 syzop Status acknowledged => closed
2015-07-19 20:01 syzop Assigned To => syzop
2015-07-19 20:01 syzop Resolution open => fixed
2015-07-19 20:01 syzop Fixed in Version => 3.4-beta1