View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0002497 | unreal | ircd | public | 2005-04-23 21:14 | 2015-08-08 17:59 |
| Reporter | Stealth | Assigned To | syzop | ||
| Priority | normal | Severity | tweak | Reproducibility | N/A |
| Status | resolved | Resolution | fixed | ||
| Product Version | 3.2.3 | ||||
| Fixed in Version | 3.4-beta1 | ||||
| Summary | 0002497: /spamfilter oper flag requirement | ||||
| Description | The spamfilter command currently requires can_gkline to use, which creates a possible abuse problem. If an oper does not have the can_gzline flag, and wants to (g)zline a user, all he needs to do is make a user spamfilter for the user he wishes to (g)zline. Because of this, the spamfilter should require can_gzline, or detect when an oper without the can_gzline flag tries to make a spamfilter with a (g)zline. Also, a better idea would be to possibly make another oper flag for spamfilter (something like can_spamfilter). This will still allow netadmins to give the can_gkline and can_gzline flags to opers, and if the opers don't know regex, they won't add a broken spamfilter that ends up glining the whole network. | ||||
| Tags | No tags attached. | ||||
| 3rd party modules | |||||
|
|
@The broken spamfilter argument-- what the hell are they doing using a feature they don't understand on a live net? :P That aside, seperating the perms might be a good idea. |
|
|
When I introduced spamfilter I didn't want to add a can_spamfilter flag because that would mean pretty much everyone would have to update his/her oper blocks, and then I think spamfilter would be quite less popular. That said, I know a can_spamfilter flag would be better from a security/limitation perspective. About those can_gzline things.. to be honest, I never understood this "fine grained" stuff... Like what security does it add if someone kan GLINE (can_gline) but not GZLINE (can_gzline) or vice versa? Can someone give me some good arguments about that? It never made sense to me... |
|
|
Spamfilter is used by so many more people than it started out being used by. I am sure by now every netadmin is ok with updating their conf each update, and it should not be too much work to add 1 flag to all their opers that know regex. I don't really know the big usage differences between zline and kline (other than their banning methods)... I mainly made this bug for a can_spamfilter flag, but making it can_gzline as the requirement at the least. |
|
|
@syz- I can understand what you're saying with regards to gzline/gline, but for example, kline/gzline should definatly be kept seperate. Perhaps the "action" you're allowed to specify on spamfilter should relate back to your permissions, ie you can't specify a gzline action unless you have the gzline flag, but you will always be able to say, specify block. |
|
|
Well, other than banning methods, GZ:Line also has the side-effect that it can apply to servers (though not immediately) due to the fact that it applies sooner in the connection process (immediately). I'd probably refrain from allowing opers to be able to (g)zline unless they also had something like /operserv JUPE access. It would be nice if they couldn't circumvent this via /spamfilter - even if it'd be tough to cause a server to GZline itself like that... Though, I'd probably never use (g)zline in spamfilter anyway, since by the logic I mentioned above, gzline can be a little more dangerous, though I'll refrain from giving examples here because I'm tired as heck (it's 23:15...) and might just make myself sound stupid (probably already have)... |
|
|
yeah, that's probably it [@can affect servers]. I'll consider can_spamfilter (but I won't promise anything) ;). If that doesn't happen then not allowing the (g)zline target if no can_gzline/can_zline flag makes sense indeed. |
|
|
Please add can_spamfilter and separate it from can_gkline, we have a similar issue with this on our network. The inclusion of spamfilter access in can_gkline is so powerful we dont like to give it to many opers...so then they cant use the weaker gline and shun commands. Thanks Guys, Edward |
|
|
This issue could probably be closed, most likely won't happen in 3.2.x, and U4 already has command-specific permissions for opers. |
|
|
yeah, this was planned for 3.3* but since that's out... won't change for 3.2* due to too much impact when in stable ircd series. |
|
|
I think we can reconsider this (can_spamfilter) |
|
|
Fixed by new oper privilege system. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2005-04-23 21:14 | Stealth | New Issue | |
| 2005-04-25 22:19 | w00t | Note Added: 0009811 | |
| 2005-04-26 21:49 | syzop | Note Added: 0009822 | |
| 2005-04-26 23:16 | Stealth | Note Added: 0009826 | |
| 2005-04-30 02:47 | w00t | Note Added: 0009866 | |
| 2005-05-01 01:26 | aquanight | Note Added: 0009868 | |
| 2005-05-01 08:54 | syzop | Note Added: 0009870 | |
| 2005-12-17 21:08 | edwardelric | Note Added: 0010872 | |
| 2007-04-19 03:15 |
|
Relationship added | has duplicate 0003209 |
| 2007-04-27 05:09 |
|
Status | new => feedback |
| 2007-06-22 04:38 |
|
Relationship added | has duplicate 0003167 |
| 2007-09-08 13:23 | Stealth | Note Added: 0014765 | |
| 2007-09-10 04:51 | syzop | QA | => Not touched yet by developer |
| 2007-09-10 04:51 | syzop | U4: Need for upstream patch | => No need for upstream InspIRCd patch |
| 2007-09-10 04:51 | syzop | Status | feedback => closed |
| 2007-09-10 04:51 | syzop | Note Added: 0014768 | |
| 2007-09-10 04:51 | syzop | Resolution | open => wont fix |
| 2012-03-03 10:00 | syzop | Note Added: 0016937 | |
| 2012-03-03 10:00 | syzop | Status | closed => acknowledged |
| 2012-03-03 10:00 | syzop | Resolution | wont fix => open |
| 2015-08-08 17:59 | syzop | Note Added: 0018642 | |
| 2015-08-08 17:59 | syzop | Status | acknowledged => resolved |
| 2015-08-08 17:59 | syzop | Fixed in Version | => 3.4-beta1 |
| 2015-08-08 17:59 | syzop | Resolution | open => fixed |
| 2015-08-08 17:59 | syzop | Assigned To | => syzop |
