View Issue Details

IDProjectCategoryView StatusLast Update
0002497unrealircdpublic2015-08-08 17:59
ReporterStealth Assigned Tosyzop  
PrioritynormalSeveritytweakReproducibilityN/A
Status resolvedResolutionfixed 
Product Version3.2.3 
Fixed in Version3.4-beta1 
Summary0002497: /spamfilter oper flag requirement
DescriptionThe 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.
TagsNo tags attached.
3rd party modules

Relationships

has duplicate 0003209 resolvedstskeeps Big spamfilter issue. 
has duplicate 0003167 resolvedstskeeps all oper "classes" should get can_zline, and spamfilter should be separated 

Activities

w00t

2005-04-25 22:19

reporter   ~0009811

@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.

syzop

2005-04-26 21:49

administrator   ~0009822

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...

Stealth

2005-04-26 23:16

reporter   ~0009826

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.

w00t

2005-04-30 02:47

reporter   ~0009866

@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.

aquanight

2005-05-01 01:26

reporter   ~0009868

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)...

syzop

2005-05-01 08:54

administrator   ~0009870

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.

edwardelric

2005-12-17 21:08

reporter   ~0010872

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

Stealth

2007-09-08 13:23

reporter   ~0014765

This issue could probably be closed, most likely won't happen in 3.2.x, and U4 already has command-specific permissions for opers.

syzop

2007-09-10 04:51

administrator   ~0014768

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.

syzop

2012-03-03 10:00

administrator   ~0016937

I think we can reconsider this (can_spamfilter)

syzop

2015-08-08 17:59

administrator   ~0018642

Fixed by new oper privilege system.

Issue History

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 stskeeps Relationship added has duplicate 0003209
2007-04-27 05:09 stskeeps Status new => feedback
2007-06-22 04:38 stskeeps 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