search

ergochat / ergo

A modern IRC server (daemon/ircd) written in Go.
https://ergo.chat/
MIT License
2.29k stars 181 forks source link

sandboxing functionality #1602

Open slingamn opened 3 years ago

slingamn commented 3 years ago

This is coming from #1583. Here's the idea: you should be able to designate some users as "sandboxed". A sandboxed user can only join a whitelisted set of channels (e.g., "#help", "#appeals"). They cannot send DMs. Some configurations may want to preemptively sandbox all non-SASL'ed users.

Unclear at this point: how should sandboxed status be set and unset on connected users? Could it be a special umode like +Z, that the user can't set and unset (but which operators can set and unset with SAMODE?)

DanielOaks commented 3 years ago

mm, it's worth looking into prior art on this. if the user can only message specific channels, it may be worth joining them to that channel / those channels when the sandbox is applied to 'em?

prdes commented 3 years ago

It could be done that way.. currently the bot does the soft ban which kbans from all channels but in the reason or via dm i need to write to them that they may appeal in #appeals for example. I'd rather they get SAJOINed to the appeals channel

DanielOaks commented 3 years ago

yeah, especially since the 'sandbox' stage is basically one stage before banning them from the network altogether.

slingamn commented 3 years ago

This can be a switch in the config: autojoin: #appeals

slingamn commented 3 years ago

The primary use case involves preemptively applying this to users via the UBAN system. This might be an additional "soft UBAN" type, analogous to require-sasl? (In this case, there is an additional question about extending require-sasl and this new UBAN type to include NUH bans, which I'm tentatively -1 on.)

DanielOaks commented 3 years ago

UBAN sandbox etc?? idk

slingamn commented 3 years ago

I was thinking this should probably be a (non-user-modifiable) user mode.

slingamn commented 3 years ago

Koragg mentions the original RFC2812 +r "restricted" mode as a possibility for this, which is rather appealing.

We could also use +S (for "sandboxed").

DanielOaks commented 3 years ago

I wouldn't mind +S. +r always trips me up with 'registered' so I'd rather not use that if possible.

slingamn commented 3 years ago

Notes:

  1. We don't currently have a registered mode for either users or channels (#1354)
  2. Unreal uses +r as a usermode for registered nicks; this is not documented correctly
  3. +S is also conflicted with Unreal (they use it for services)
DanielOaks commented 3 years ago

I don't mind whichever one we go with, but the +r - registered association has and will always exist for me, hard habit to break but that's prolly just me. If we're calling the feature 'sandboxing' it also makes a bit more sense to use +S than +r in my mind. wrt conflicting, almost every umode char conflicts unfortunately, I took a look through ircdefs and didn't find any other existing chars we could reuse.

grumble grumble named modes grumble

slingamn commented 3 years ago

+x and +X have a nice ring to them in this context. +X is apparently unused; I think +x would be fine too though (Unreal uses it for toggling a cloak?)

slingamn commented 3 years ago

I've been struggling with how this should interact with the account system. Here's what I'm thinking:

  1. IP-based sandboxing rules should exempt anyone who logs in during connection registration (via SASL or PASS-stuffing)
  2. but there should be a way to set an account as sandboxed, so that any connection associated with that account (whether or not it's always-on) gets sandboxed until an operator lifts the restriction
slingamn commented 3 years ago

I think this project may be cancelled. The original deployment that asked for it is no longer interested in switching. For everyone else, it's probably better addressed with existing tools: making +R a default channel and user mode, and then setting an #appeals channel -R.