View Issue Details

Jump to NotesJump to History
IDProjectCategoryView StatusDate SubmittedLast Update
0004013unrealircdpublic2011-03-15 14:452015-08-08 08:32
Reporterkatsklaw Assigned Tosyzop  
PrioritynormalSeverityfeatureReproducibilityN/A
Status resolvedResolutionfixed 
Product Version3.2.9-RC1 
Fixed in Version3.4-beta1 
Summary0004013: Add multiple allow::hostname
DescriptionAt present if I wanted to get restrictive with my allow block host names I'd have to have an entire allow block for each of them. Thus making maintaining them that much harder as I'd have to update every single block and that could get rather ugly.

Using multiple host names just like in the oper block will solve that.
Additional InformationAllowing multiple allow::ip would also be logical.
TagsNo tags attached.
3rd party modules

Activities

katsklaw

2011-03-15 14:48

reporter   ~0016621

Last edited: 2011-03-15 14:50

 Like such:

allow {
    ip *;
    hostname *;
    class clients;
    maxperip 5;
};

allow {
    ip *;
    hostname *@*.aol.com;
        hostname *@*.msn.com;
        hostname ~*@*;
    class clients2;
    maxperip 3;
};

allow {
    ip *@127.*;
        ip *@10.*;
        ip *@192.168.1.*;
    hostname NOBODY;
    class local-clients;
    maxperip 30;
};

ohnobinki

2011-03-15 15:08

reporter   ~0016622

With the current behavior of ip and hostname being ANDed, it would seem to make most sense for all of the hostnames to also be ANDed together, meaning that hostname *@*.aol.com; and hostname *@*.msn.com; would cause the allow block to match _nobody_ ;-).

So, do you want that sort of behavior changed too? (May you at least suggest how these semantics should be changed?)

katsklaw

2011-03-15 17:49

reporter   ~0016623

Perhaps OR is better than AND, then also make ip and hostname optional but require one. Meaning make it so I can use ip without hostname or vice versa as long as either an ip mask or a hostname mask is defined.

If both are defined use the current AND system.

perhaps:

allow {
    hostname *@*.aol.com;
    hostname *@*.msn.com;
    hostname ~*@*;
    class clients2;
    maxperip 3;
};

allow {
    ip *@127.*;
    ip *@10.*;
    ip *@192.168.1.*;
    class local-clients;
    maxperip 30;
};

or maybe even stack into a single line and comma delimit the field:

allow {
    hostname *@*.aol.com, *@*.msn.com, ~*@*;
    class clients2;
    maxperip 3;
};

allow {
    ip *@127.*, *@10.*, *@192.168.1.*;
    class local-clients;
    maxperip 30;
};

ohnobinki

2011-03-15 18:38

reporter   ~0016624

What I said about changing the semantics about having both ip and hostname blocks there is probably unnecessary. You might want to whitelist a couple of IPs and at the same time require those whitelisted IPs to have certain rDNS, which you would do with an ORing of multiple hostnames ANDed with an ORing of different IPs which fits your example. So if we clearly define this behavior, I think we can do that ;-).

Concerning comma delimiting, I don't think the config parser supports that. However, with the examples of at the help.conf file or at oper::flags, we normally do that sort of thing with config blocks instead:

hostname { *@*.aol.com; *@*.msn.com; ~*@*; };
ip { *@127.*; *@10.*; *@192.16.1.*; };

The config parser can be easily enough made to accept either of those, meaning this change can be backwards/forwards compatible. But enforcing the more accept {} blocks would need some time to patch up.

katsklaw

2011-03-16 16:04

reporter   ~0016625

hostname { *@*.aol.com; *@*.msn.com; ~*@*; };
ip { *@127.*; *@10.*; *@192.16.1.*; };

Definitely fits current scheme better than comma delimiting. I'm game for which ever is easier to be sure. :)

syzop

2015-08-08 08:32

administrator   ~0018576

This is implemented in beta1?2? well. it's done.

Issue History

Date Modified Username Field Change
2011-03-15 14:45 katsklaw New Issue
2011-03-15 14:48 katsklaw Note Added: 0016621
2011-03-15 14:50 katsklaw Note Edited: 0016621
2011-03-15 15:08 ohnobinki Note Added: 0016622
2011-03-15 17:49 katsklaw Note Added: 0016623
2011-03-15 18:38 ohnobinki Note Added: 0016624
2011-03-16 16:04 katsklaw Note Added: 0016625
2011-03-27 23:38 mahdkoosh Tag Attached: OPER
2011-03-28 10:17 mahdkoosh Tag Detached: OPER
2015-08-08 08:32 syzop Note Added: 0018576
2015-08-08 08:32 syzop Status new => resolved
2015-08-08 08:32 syzop Fixed in Version => 3.4-beta1
2015-08-08 08:32 syzop Resolution open => fixed
2015-08-08 08:32 syzop Assigned To => syzop