HostServ: re-check the forbidden list when activating a vhost request

REQUEST rejected a forbidden host, but ACTIVATE never re-checked, so a
pattern forbidden after a request was filed was granted on approval. The
activate path now re-reads the forbidden list. Operator SET stays an
intentional override (unchanged), so the check lives in approve, not the
shared prepare_vhost.
This commit is contained in:
Jean Chevronnet 2026-07-16 03:25:27 +00:00
parent b749cd2969
commit dabb18abd4
No known key found for this signature in database
2 changed files with 13 additions and 0 deletions

View file

@ -34,6 +34,12 @@ pub fn handle(me: &str, from: &Sender, args: &[&str], ctx: &mut ServiceCtx, net:
return;
}
};
// The forbidden list may have grown since the request was filed; a user's
// request must still obey it (an operator's own SET is a deliberate override).
if db.vhost_is_forbidden(&host) {
ctx.notice(me, from.uid, format!("Can't activate: \x02{host}\x02 is on the forbidden list."));
return;
}
match db.set_vhost(account, &host, from.nick, None) {
Ok(()) => {
for uid in net.uids_logged_into(account) {

View file

@ -2324,6 +2324,13 @@
assert!(says(&hs(&mut e, "000AAAAAB", "WAITING"), "No vhost requests"), "no request left after reject");
// A non-operator can't approve.
assert!(says(&hs(&mut e, "000AAAAAV", "WAITING"), "Access denied"), "oper-gated");
// A host forbidden AFTER its request is filed must not slip through ACTIVATE.
hs(&mut e, "000AAAAAB", "REQUEST evilcorp.example");
hs(&mut e, "000AAAAAB", "FORBID (?i)evilcorp");
let out = hs(&mut e, "000AAAAAB", "ACTIVATE boss");
assert!(says(&out, "forbidden list"), "activate refused for a now-forbidden host: {out:?}");
assert!(!out.iter().any(|a| matches!(a, NetAction::SetHost { .. })), "no vhost applied when forbidden: {out:?}");
}
// StatServ reports per-channel activity (#channel) and the global registry