View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0001306 | unreal | ircd | public | 2003-10-16 13:02 | 2003-10-27 14:24 |
| Reporter | us44ever | Assigned To | |||
| Priority | normal | Severity | feature | Reproducibility | N/A |
| Status | closed | Resolution | open | ||
| Product Version | 3.2-beta18 | ||||
| Summary | 0001306: Feature request - restricting ircop or other server's ircop's power from the main hub | ||||
| Description | I think most/all people would be interested in this feature. all irc networks link's new servers to their network from time to time (sometimes they don't know about the owner of that server who wants to link) from which, that server admin may abuse his powers! what I'm suggesting is that to give more features to be used for servers ( hub's only ) such as: controlling the ircop's access in some server ( not allowing any ircop from that server to see the user's real ip "if the ip encryption is enabled" , ...etc) I think you know about the rest of features simply because all ya own a network or atleast admin some server Another suggestion is that adding a new flag to the ircop list from which server owner can add ircop's that can't get a user real ip (in the ip encryption feature is enabled) or in generally adding a flag and calling it "ircop in test period" which by default have some restricted flags so that he/she can't abuse anything in the network. I think I've written a very long story, i hope you guys got the general idea, this feature will be very helpful for network owners. Thanks, and god bless... | ||||
| 3rd party modules | |||||
|
|
Well it's not possible to hide information to other servers, that would f*ck cloaking up. About adding a flag that hides real ip/host information, that's theoretically possible but: - it won't solve your problem with a new server, servers need full info so the person could modify his ircd or snif the network to get real ips of all users. - I never understood that feature, ircops are there to protect/manage the network, like managing kline/glines... how can they properly do that without that info ;). Hm ok, I guess you'll say that they shouldn't do that kind of tasks in the beginning, maybe you got a point there... Another important point is that it would be a pain to code (/me thinks of: whois, who, snomask +c/protoctl acf, all server notices which contain user ips, etc..) :p. I do know that usually when a new server is added they are not allowed to have netadmins/services-admins on their server (eg: only 1 admin and an oper)... Now one could think of some system that when an oper tries to become netadmin it immediately -N's (remove netadmin) it etc... that's quite simple to add but it would only work if they _accidently_ try to become netadmin, if they are trying to evade the rules on-purpose or are trying to destroy your network it's very hard to stop them. There was an option called 'quarantine' once, but it wasn't doing much.. I think the idea was that users at the remote server were only allowed to have local ops (or maybe it was even going further). I'm not really in favor of all these things if it's possible to circumvent the "security" (/me is very much against a false sense of security, eg: security on the client side), stopping glines/gzlines/shuns would be possible and quite easy, but stopping kills is not so easy... like.. do you allow nick collisions or not? if not, then you'll get a server fight, if you do then they could send a bogus kill which gets through... that kind of things ;). |
|
|
That Idea with stripping the "N" mode isn't new. Auspice Services have already that option, that only SRA (Services Root Admin) are allowed to have +N, otherwise, services are setting -N. You will never have 100% security. When you accept a new server link, you should know the admin of it. Normally, it is a good idea, that the one, who want to link, will stay for 1-2 weeks on the network :P |
|
|
Yes, well I'm sure neither me nor codemastr was planning to do this kind of crap (or at least in the next X months).. so *close bugreport*. |
