View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0001638 | unreal | ircd | public | 2004-03-09 11:53 | 2004-06-01 20:15 |
| Reporter | Dukat | Assigned To | |||
| Priority | normal | Severity | feature | Reproducibility | N/A |
| Status | closed | Resolution | open | ||
| Summary | 0001638: New Usermode: Block DCC Requests | ||||
| Description | I think a new Usermode to Block DCC Requests (similar to CR's +e) would make a great addition. When this mode is set, dcc transfers cannot be sent to the client (and from the client). Think of it: Set this Usermode +e on all clients connecting (in set::modes-on-connect), so no one can use DCC. If the user really NEEDS to use DCC, he can manually set -e. This way there is no way for trojans or viruses to be distributed to innocent users, unless they really know what they are doing and set themselves -e. If Serveradmins don't want to allow DCC on their server at all, they can just set e to the set::restrict-usermodes. You can even take this idea further: If the Spamfilter blocks a file and from this point on denies DCC from this user: Why don't just set him +e and disallow to unset this usermode? This would be quite an intuitive behavior. | ||||
| 3rd party modules | |||||
|
|
Well, if you wanted DCC Protection like that, first of all do *NOT* auto-accept DCCs! After that, you could do this: Put this "mode" in set::modes-on-connect and in set::retrict-umodes, as mentioned. If two people really need to exchange a file, a Service Admin can ask Services (if you use them) to SVSMODE -e on both users. Then put it back when the connection is established (since, once started, DCC runs independantly of the server). |
|
|
as for denying all dccs for everyone: you can simply add a deny dcc block for "*". as for spamfilter & marking the user as unable to send any dccs: we already have that if you choose action 'dccblock'. As for your original idea, the mode... I don't know.. I personally don't think it's that useful now anymore these days and only annoying. That said, I don't know how codemastr thinks about it, but it could also easily be done in a module. |
|
|
Well it's NOT about blocking anything for anybody - if you wanted to do that, you really could just use a deny dcc Block for *, sure. I just mentioned that set::restrict-usermodes-Thing as a possibility. The basic idea behind setting such a mode on connect is really just to protect innocent (helpless?) users - every user who NEEDS dcc WILL just unset the mode (but he WILL have to do that - like saying "I know what i am doing"). It's a really simple and efficient way to protect the users. About the Spamfilter: I just thought this would be another benefit - of course the way it is now is working - it just would be more... logic? intuitive? don't know... I just thought: You have serveral possibilities: "kill" equals /kill, "tempshun" equals /tempshun, etc. But "dccblock" is just... there... not really a feature that exists in the IRCd. So... why don't just make it a feature? *g* (Ok, i admit: "viruschan" stays kinda strange - there's no such command for it as there is for the other possibilites) But the Spamfilter of course wasn't the main reason for requesting this usermode =) |
|
|
I'm not really against the idea, just the explanation. Like for the "you must set -e to use dcc" well, that's similar to what DALnet did way back. To prevent people from receiving trojans. So what happened? Everyone loaded scripts to just -e on connect. And even worse, trojans were set to auto -e on DALnet so that they could receive files without the person knowing. In the end it resulted in /dccallow. |
|
|
That could really be the problem, if everbody just uses a script to set -e, the effect is gone... BUT it still would protect novice users from getting malicious files, wouldn't it? But maybe a /dccallow - Command would be better... Although it must not be possible for users to transfer files which are in the "dcc deny" block just by using /dccallow... There usually is a reason for something to be in the dcc deny block, so if the Admin does not want the users to distribute let's say *.exe files, it must not be possible to circumvent that. But maybe somebody has an even better idea? :-) |
|
|
Yeah, /dccallow, that feature suggestion is now reported over a year ago. But still not added :/ Look http://bugs.unrealircd.org/bug_view_advanced_page.php?bug_id=0000551 |
|
|
And a second thing: Disallowing users, to send dcc files, when ONE file gets blocked, UNTIL he reconnect is annoying too. When someone forgot to rename the file, he gets blocked. He must reconnect, and he will loose all temp ops, etc etc.. I don't understand, why someone get totally blocked, and not for a few minutes, or never. The server will block the defined files again, if he tries it a second time. Just to mention it. |
|
|
[Dukat] >That could really be the problem, if everbody just uses a script to set -e, the effect is gone... [codemastr] >Everyone loaded scripts to just -e on connect. And even worse, trojans were set to auto -e on DALnet so that they could receive files without the person knowing. That's why you'd put e in set::restrict-umodes. Then people would have to ask SAs before they can DCC Send. Or they'll have to find another method to transfer files. |
|
|
Thus creating a whole lot more work for administration... Is it really worth it? |
|
|
I think it's best to close this bug... There's a module out there (noctcp or something, see unrealircd.com -> modules) that has a usermode that blocks dccs.. And as others said, a usermode is probably not really the best way to do it, and DCCALLOW -> 0000551 (perhaps I'll have a look at that ;p). |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2004-03-09 11:53 | Dukat | New Issue | |
| 2004-03-09 13:26 | aquanight | Note Added: 0005381 | |
| 2004-03-09 14:14 | syzop | Note Added: 0005384 | |
| 2004-03-09 15:16 | Dukat | Note Added: 0005387 | |
| 2004-03-09 20:11 |
|
Note Added: 0005389 | |
| 2004-03-11 10:24 | Dukat | Note Added: 0005413 | |
| 2004-03-11 14:15 | Rocko | Note Added: 0005418 | |
| 2004-03-11 14:21 | Rocko | Note Added: 0005419 | |
| 2004-03-11 18:47 | aquanight | Note Added: 0005438 | |
| 2004-03-11 19:13 | w00t | Note Added: 0005439 | |
| 2004-06-01 20:15 | syzop | Status | new => closed |
| 2004-06-01 20:15 | syzop | Note Added: 0006529 |
