View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0000551 | unreal | ircd | public | 2002-12-15 12:27 | 2004-06-09 22:29 |
| Reporter | jollino | Assigned To | syzop | ||
| Priority | normal | Severity | feature | Reproducibility | N/A |
| Status | closed | Resolution | open | ||
| Product Version | 3.2 | ||||
| Summary | 0000551: DccAllow list to bypass the dccdeny feature | ||||
| Description | (This is a feature suggestion) I don't know if it's been already suggested, but here it goes: sometimes a user would want to receive a denied file (for instance: .exe) by a given user whom he trusts. He could add this user in his dccallow list, which should work pretty much like the silence or the watch list, so the dccdeny filter won't be used when he receives files from that sender. Moreover, the whole dccdeny stuff could be used within different levels, possibly settable in the networks file, such as: level 0 - ignore dccdeny even if it's in the conf level 1 - block those files but don't disable the dcc send for the lame client (therefore allowing the dirty user to still send non-denied files) level 2 - block those files and disable each subsequent send unless the dirty user reconnects. Just my two cents. | ||||
| 3rd party modules | |||||
|
|
Well the thing is, dccdeny isn't supposed to be used to ban *.exe. it is more to ban *sub7*.exe or LIFE_STAGES.*.SHS, files that you wouldn't want under any circumstances. But I have noticed that there is another purpose admins are using it for, to ban * (all DCC Sends). Adding /dccallow would defeat their purpose. Because then they don't have the ability to block all dccsends... |
|
|
If a user uses /dccallow nick in such a case, (s)he should know what (s)he's doing. Well, actually, there's nothing certain... you could trick a newbie into doing whatever you want, if they trust you enough. But allowing (experienced) users to bypass the dccdeny system would sure be useful... |
|
|
But like I'm saying the purpose of dccdeny isn't the same as what you're thinking. If an admin blocked *.exe it isn't because they want to make sure you know what you're doing, it's because they do NOT want users to distribute exe files over their server. |
|
|
Hi. Well, *I* am using dccdeny, to prevent sends which can contain viruses, trojan horses and so on, and only for that reason. (.exe,.htm,.vbs,.com etc.) I think, I am not the only one (I hope :P). I wondered, why it never gots implemented, because bahamut have it now for a long time. I think this feature is usefull. I can't give my users the ability, to except some users from the dccdeny, and that's bad. Sure, when they want to send exe files, they can rename the files. But first, they get blocked until reconnect ... and what about bots, fileservers, xdcc-bots, and and and. When codemastr think, there are admins, which use dccdeny to prevent distributing of files, then I suggest, to add an option in the "dcc deny { };" block, which disables /dccallow for this file, OR, which allows /dccallow. (Choose one) That is maybe much work.. but possible and a good solution I think. The way, how dccallow on bahamut works is good too. Here the help for dccallow on bahamut: *** /DCCALLOW [<+|->nick[,<+|->nick, ...]] [list] [help] *** You may allow DCCs of filetypes which are otherwise blocked by the IRC server *** by specifying a DCC allow for the user you want to recieve files from. *** For instance, to allow the user bob to send you file.exe, you would type: *** /dccallow +bob *** and bob would then be able to send you files. bob will have to resend the file *** if the server gave him an error message before you added him to your allow list. *** /dccallow -bob *** Will do the exact opposite, removing him from your dcc allow list. *** /dccallow list *** Will list the users currently on your dcc allow list. Contains everything which is important ;) |
|
|
*bump* Is this a good idea? From time to time we get similar requests (for example a 'no dcc' usermode, of which now a module exists), but... Has anyone results on the practical use of this? Like I noticed bahamut has it, so I went to dalnet and tried to send myself an exe file... that just works.. That makes me wonder why they have a DCCALLOW command then.. Basically my question is.. is this really 'accepted' by users? And.. is it really still needed? For example for some time now mIRC has a block filetypes thingy that's enabled by default etc. IF it's done it would indeed require some kind of extra flag for deny dcc { } as mentioned by the original report (jollino) and Rocko. |
|
|
Well, denying DCC sends can stop the sending of MP3 files etc via DCC on an IRC server... /DCCALLOW if I am correct in my assumptions, would stop all that. In the present proposed system, I would be opposed to it. |
|
|
Well like I said, dcc deny wasn't designed to ban *.exe. It was designed to ban specific files. As I already shows, LIFE_STAGES.*.SHS. You wouldn't want that from anyone, not even your friend. It doesn't matter who sent it, it is a virus. So why should there be an option to send it? Jollino brought up that you'd only do it if you know what you are doing. But, what about scripts? I can see it now. A new trojan exists that DCC Sends MyTroj.exe. So, rightfully, admins ban that file. So what happens? The IRC client that comes with MyTroj.exe is designed to /dccallow +the_master so that newer, updated versions of MyTroj.exe can still be received. This effectively limits the purpose of dcc deny. However, people are right, it is being used to ban *.exe, not just specific files. I don't personally like the idea, but I wouldn't be against adding it. |
|
|
Yeah I mean a per-item setting on whether to allow /dccallow to override it (default: no) [didn't notice jollino was talking about a GLOBAL setting, that's of course not what I want..] It doesn't look too hard, plus I got some time for it, but I hate coding stuff that will be rarely used ;). |
|
|
Well I'm sure former Bahamut users will use it, since they are used to it. Note though, if you do make this, as per the discussions we've had, make sure to use the same numerics as Bahamut :P |
|
|
syzop, I don't know why it did worked for you sending *.exe files on DALnet, but I know, that this is normally not possible, until you do a /dccallow +nick. And I tested it too. [13:44:25] -Rocko2- DCC Send Unreal3.2.exe (80.185.73.219) - [13:44:25] -broadway.ny.us.dal.net- Rocko2 ([email protected]) has attempted to send you a file named Unreal3.2.exe, which was blocked. - [13:44:25] -broadway.ny.us.dal.net- The majority of files sent of this type are malicious virii and trojan horses. In order to prevent the spread of this problem, we are blocking DCC sends of these types of files by default. - [13:44:25] -broadway.ny.us.dal.net- If you trust Rocko2, and want him/her to send you this file, you may obtain more information on using the dccallow system by typing /dccallow help /dccallow +Rocko2 [13:45:08] *** Rocko2 has been added to your DCC allow list THEN it's possible to send the file, after adding him temporarily to the dcc allow list. /dccallow list [13:48:24] *** The following users are on your dcc allow list: [13:48:24] *** Rocko2 ([email protected]) [13:48:24] *** End of DCCALLOW list Well, how will you make dccallow? an option for the dccdeny block, to allow /dccallow? And then handle it like bahamut does? (dccallow list, accept /dccallow for all items with "dccallow" flag in dcc deny blocks when added to an /dccallow list?) My questions sounds as complicated as they are lol ;) Oh and Rocko2 got: [13:44:25] *** (s) The user Rocko3 is not accepting DCC sends of filetype *.exe from you. Your file Unreal3.2.exe was not sent. Well, let me know when you implemented it, I will test it ;) bearbeitet am: 2004-06-04 08:02 |
|
|
'syzop, I don't know why it did worked for you sending *.exe files on DALnet' Yeah, I found out dccs to yourself are not filtered (what a useless feature ;p). 'an option for the dccdeny block, to allow /dccallow? And then handle it like bahamut does?' Yup (@both) :P. I've been reading the bahamut source because I don't want any major inconsistencies (commands that work differently, numerics fun, and things like that). |
|
|
"The majority of files sent of this type are malicious virii and trojan horses. In order to prevent the spread of this problem, we are blocking DCC sends of these types of files by default" Syzop, if you put that message in Unreal, I'll have to kill you :) Virii is not a word!!!!! It was created by some stupid moron who didn't know Latin but wanted to pretend he did. He took the word radius, and said the plural is radii, therefore virus must be virii. NO! The plural of "us" is "i". See, radIus already has an i in it. It didn't add two, it added one. If "us" was "ii", then it would be "radiii". But it isn't, it is "radii." If anything, "virus" would be "viri", but it isn't! The correct plural form of "virus" is "viruses." There are plenty of English words that end in "us" but don't use "i" in the plural. Caucus, discus, and genus, just to name a few. Anyone who knows a little Latin knows why it isn't "viri." Yes, that would be the correct Latin, but even in Rome, it was never really used. The reason was, the word "vir," means man, and "viri," means men. Since both words are nouns, it could lead to confusion. So even among the Ancient Romans, if they saw "viri" they assumed "men" not "viruses." Latin has butchered the English language enough due to its misuse. The example that comes to mind is "octopus." According to most dictionaries, the plural is either "octopuses" or "octopi." However, the word "octopus" doesn't even come from Latin! So why would it use a Latin ending? It comes from the Greek meaning eight-footed. And, the plural in Greek derivation would make it "octopods." Sorry for the rant, it just really angers me when I see someone use "virii" :) |
|
|
Yeah I fully agree, I hate that word... I already used the term 'viruses' for that text [for unreal] ;). |
|
|
>#0006584 LOL Well, in that case, let's go kill the bahamut coders for writing that ;) . If a notice like that does go into Unreal, though, (with the _correct_ plural for 'virus'), I'd rather see it in the /helpop for DCCALLOW, than everytime someone tries to send me a bad file. *edit* ACK syzop beat me :( */edit* edited on: 2004-06-04 13:46 |
|
|
Added in .51. Hopefully not with too many bugs (diff is 1400 lines) ;). Feel free to test! |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2003-09-18 19:29 | Rocko | Note Added: 0003681 | |
| 2004-06-01 20:40 | syzop | Note Added: 0006530 | |
| 2004-06-01 20:40 | syzop | Status | acknowledged => feedback |
| 2004-06-01 22:06 | w00t | Note Added: 0006532 | |
| 2004-06-01 22:49 |
|
Note Added: 0006534 | |
| 2004-06-01 23:25 | syzop | Note Added: 0006537 | |
| 2004-06-02 00:17 |
|
Note Added: 0006540 | |
| 2004-06-02 00:20 | syzop | Status | feedback => assigned |
| 2004-06-02 00:20 | syzop | Assigned To | => syzop |
| 2004-06-02 00:21 | syzop | ETA | none => < 1 month |
| 2004-06-02 00:21 | syzop | Product Version | 3.2-beta13 => 3.2 |
| 2004-06-04 00:20 | syzop | ETA | < 1 month => < 1 week |
| 2004-06-04 07:53 | Rocko | Note Added: 0006576 | |
| 2004-06-04 08:02 | Rocko | Note Edited: 0006576 | |
| 2004-06-04 11:04 | syzop | Note Added: 0006578 | |
| 2004-06-04 13:34 |
|
Note Added: 0006584 | |
| 2004-06-04 13:44 | syzop | Note Added: 0006586 | |
| 2004-06-04 13:45 | aquanight | Note Added: 0006587 | |
| 2004-06-04 13:46 | aquanight | Note Edited: 0006587 | |
| 2004-06-08 22:50 | syzop | ETA | < 1 week => 2-3 days |
| 2004-06-09 22:29 | syzop | Status | assigned => closed |
| 2004-06-09 22:29 | syzop | Note Added: 0006628 |
