View Issue Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
0002667 | unreal | ircd | public | 2005-10-30 15:22 | 2023-07-07 16:46 |
Reporter | JasonTik | Assigned To | syzop | ||
Priority | normal | Severity | feature | Reproducibility | N/A |
Status | resolved | Resolution | fixed | ||
OS | ALL | OS Version | ALL | ||
Product Version | 3.2.4 | ||||
Fixed in Version | 6.1.2-rc1 | ||||
Summary | 0002667: Restricted remote includes | ||||
Description | < < < <SNIP> < < It would be nice to be able to specify a list of blocks that would be accepted from a possibly untrusted remote include. It would allow people to distribute lists of spammers or whatever without me having to worry the would put an oper in for themselves in the future. | ||||
Tags | No tags attached. | ||||
3rd party modules | |||||
|
Interesting, though in a case like this it may be more appropriate to just have a cronjob wget the remote include, grep it for any invalid blocks (will come up with a regex for this later - maybe!), remove said blocks as appropriate, cp final result to usable location, kill -HUP `cat ircd.pid`, etc. Also - what would unreal do with a remote conf that did have a "disallowed" block? |
|
this is whatfor dnsbl and other spamlists are made for. |
|
... What are you on about pinstrate? This is _nothing_ to do with dnsbl, ahbl, or any other blacklist. Allow me to clarify what we're talking about. Let's say I link to a new network, and they want me to use a remote include for what they tell me is 'permanent glines' - I might want to make SURE that it couldn't have anything silly, like.. let's say, an extra o:line for them on MY server. THAT is what we are talking about here. --- That aside, I'd also wonder how it would work where say, one server had a module that fiddled around with some configuration stuff, and the other one didn't.. but then, we already work around that kind of a situation in extban synching stuff, etc.. so I guess it'd even out. |
|
I should point that the situation mentioned here has a trust issue to it. Iow: if you don't trust the admin for a remote include - don't include! It makes more sense to do this kind of thing with public remote includes such as spammer lists or even the CVS spamfilter.conf, limiting the set of available blocks in case some sneaky hacker decides to add some extra blocks to the config (although for both cases, worse damage could be done with the blocks that *are* available - ban user/ip { mask *@*; }; spamfilter { regex "."; target user; }; etc...) |
|
aquanight's first post: It would ignore the allowed block, possibly log a warning. aquanight's second post: It doesnt always have to be like that, it could be netwide Vhosts (I know there are better ways to do this, just an example). You cant do much damage making one of those for yourself, since I will ban you by realip. |
|
This idea has been mentioned before, and I don't know yet, I think it's nice, but it's just not on the very top of my list ;). A very similar idea will be used for the distributed spamfilter (which would only allow spamfilter { } and some other blocks), though that is all done internally. |
|
+1 |
|
https://github.com/unrealircd/unrealircd/commit/0af88581d380602bfd58a0cdaa36b714fb7ef3c3 Syntax is something like: include "whatever" { restrict-config { nameofblockallowed; } } |
Date Modified | Username | Field | Change |
---|---|---|---|
2005-10-30 15:22 | JasonTik | New Issue | |
2005-10-31 00:36 | aquanight | Note Added: 0010618 | |
2005-10-31 00:37 | aquanight | Note Edited: 0010618 | |
2005-10-31 01:22 | pinstrate | Note Added: 0010620 | |
2005-11-02 21:48 | w00t | Note Added: 0010624 | |
2005-11-02 22:35 | aquanight | Note Added: 0010625 | |
2005-11-04 18:05 | JasonTik | Note Added: 0010638 | |
2005-11-09 08:56 | syzop | Note Added: 0010678 | |
2006-11-12 15:22 | syzop | Status | new => acknowledged |
2013-01-26 10:55 | katsklaw | Note Added: 0017388 | |
2023-07-07 16:46 | syzop | Assigned To | => syzop |
2023-07-07 16:46 | syzop | Status | acknowledged => resolved |
2023-07-07 16:46 | syzop | Resolution | open => fixed |
2023-07-07 16:46 | syzop | Fixed in Version | => 6.1.2-rc1 |
2023-07-07 16:46 | syzop | Note Added: 0022945 |