View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0003148 | unreal | ircd | public | 2006-12-17 01:37 | 2015-07-19 20:01 |
| Reporter | avb | Assigned To | syzop | ||
| Priority | normal | Severity | tweak | Reproducibility | N/A |
| Status | closed | Resolution | fixed | ||
| OS | Any | OS Version | Any | ||
| Product Version | 3.2.6 | ||||
| Fixed in Version | 3.4-beta1 | ||||
| Summary | 0003148: Is local operator privileges should be reduced? | ||||
| Description | Why 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? | ||||
| Tags | No tags attached. | ||||
| 3rd party modules | |||||
|
|
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 |
|
|
why you make someone ircop (local!) when you dont trust him to not even send/receive globops? |
|
|
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 |
|
|
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? |
|
|
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 ;-) |
|
|
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. |
|
|
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? |
|
|
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 |
|
|
We should implement more flexible oper classes, like, classes defined in .conf or something. |
|
|
There's no locop anymore in 3.4-beta1 so... fixed. |
| 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 |
|
Note Added: 0013771 | |
| 2007-04-27 03:18 |
|
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 |
