Re: [Coder-Com] adding multi-accept
> have you considered adding the multi-accept capability to the > server? Feel free to send a patch to patches@--please include ChangeLog entries and a commit message. If you can't do that, we'll try to look into it when we get a chance, but it might be a while. -- Kevin L. Mitchell <[EMAIL PROTECTED]>
[Coder-Com] level 500 command proposal
Hello. Almost everybody knows that if you have sufficient access in a channel to set a ban through X and you set that ban on *!*@*.* X will kick all users from that channel. You need access level >= ban level to remove it. The problem is that the username's password can be stolen. So, with a stolen password and sufficient access you can kick out an entire channel. This sucks... My proposal is to add a new channel setting (level 500). For example FULLBAN (OFF or ON) which allow (or not) users to set bans on *.* . I guess is a good ideea... 10x & please excuse my english. Best regards, JL` __ Do You Yahoo!? LAUNCH - Your Yahoo! Music Experience http://launch.yahoo.com
[Coder-Com] Re: [Patches] Q-lines patch (2.10.11)
> Here it is, pretty much tested and working. Thanks :) looks good, so I committed it. -- Kevin L. Mitchell <[EMAIL PROTECTED]>
[Coder-Com] Re: [Patches] Adding multi-accept
> This change implements multi-accept, based on the idea that
> poll/select can only be efficient, if we succeed in handling
> all available events, i.e. accept all pending connections.
I noticed that some of the temporary error conditions will exit the
function. You might want to consider using continues in the while
form. I'm afraid I won't accept anything that uses goto except in
error exit conditions in functions that need to do cleanups due to
stylistic prejudices.
> Additionally, a portability issue was resolved. '%m' is not
> available everywhere. It was replaced with the portable
> way of relying on strerror().
I already mentioned this to you, but ircd_snprintf() always supports
%m, so this isn't an issue.
Just to clarify what I meant earlier, take this snippet of code in
your patch:
+ if (fd > MAXCLIENTS - 1) {
+++ServerStats->is_ref;
+send(fd, "ERROR :All connections in use\r\n", 32, 0);
+close(fd);
+return;
+ }
All connections may be in use, but there may still be connections
waiting to be accepted. Our choices are to either skip those pending
connections, hoping that an fd will become available the next time
through, or we can go clear out all those pending accept()'s during
this loop. If the former, then this is fine; if the latter, then the
return needs to be changed to a continue. I guess what I'm really
asking for is if this *is* what you meant to do here--perhaps a comment
to that effect could be added to the returns. Several of the other
tests following this one do need to have the return changed to a
continue, though, such as the listener->active test or the
connection_allowed() test.
Other than that, the patch looks good. I have a slight concern about
indentation, so you might want to look at that, but it's relatively
minor, as I could correct it when I commit. If you could address my
other concerns and resubmit the patch, I'd greatly appreciate it :)
Thanks,
> 2002-05-17 Sascha Schumann <[EMAIL PROTECTED]>
>
> * ircd/listener.c (accept_listener): In the event of
> a readable listener socket, the function loops
> until accept(2) returns -1. This ensures that all
> connections which are pending at the time are accepted
> which increases the server's capacity significantly.
> Also turn '%m' into '%s' and use the portable function
> strerror(errno).
>
> - Sascha Experience IRCG
> http://schumann.cx/http://schumann.cx/ircg
>
> --8323584-452026418-1021646760=:32133
> Content-Type: TEXT/PLAIN; charset=us-ascii; name=multi-accept
> Content-Transfer-Encoding: BASE64
> Content-ID: <[EMAIL PROTECTED]>
> Content-Description:
> Content-Disposition: attachment; filename=multi-accept
>
> SW5kZXg6IGxpc3RlbmVyLmMNCj09PT09PT09PT09PT09PT09PT09PT09PT09
> PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0NClJD
> UyBmaWxlOiAvaG9tZS9jb2Rlci1jb20vY3ZzL2lyY3UyLjEwL2lyY2QvbGlz
> dGVuZXIuYyx2DQpyZXRyaWV2aW5nIHJldmlzaW9uIDEuMTcuMi4xDQpkaWZm
> IC11IC1yMS4xNy4yLjEgbGlzdGVuZXIuYw0KLS0tIGxpc3RlbmVyLmMJMjAw
> Mi8wMS8xMSAwMDoyMDozMgkxLjE3LjIuMQ0KKysrIGxpc3RlbmVyLmMJMjAw
> Mi8wNS8xNyAxNDozMTowMA0KQEAgLTQ0MiwxNSArNDQyLDMxIEBADQogICAg
> ICAqIHBvaW50LCBqdXN0IGFzc3VtZSB0aGF0IGNvbm5lY3Rpb25zIGNhbm5v
> dA0KICAgICAgKiBiZSBhY2NlcHRlZCB1bnRpbCBzb21lIG9sZCBpcyBjbG9z
> ZWQgZmlyc3QuDQogICAgICAqLw0KKw0KKyAgICAgLyoNCisgICAgICAqIFRo
> aXMgcGllY2Ugb2YgY29kZSBpbXBsZW1lbnRzIG11bHRpLWFjY2VwdCwgYmFz
> ZWQNCisgICAgICAqIG9uIHRoZSBpZGVhIHRoYXQgcG9sbC9zZWxlY3QgY2Fu
> IG9ubHkgYmUgZWZmaWNpZW50LA0KKyAgICAgICogaWYgd2Ugc3VjY2VlZCBp
> biBoYW5kbGluZyBhbGwgYXZhaWxhYmxlIGV2ZW50cywNCisgICAgICAqIGku
> ZS4gYWNjZXB0IGFsbCBwZW5kaW5nIGNvbm5lY3Rpb25zLg0KKyAgICAgICoN
> CisgICAgICAqIGh0dHA6Ly93d3cuaHBsLmhwLmNvbS90ZWNocmVwb3J0cy8y
> MDAwL0hQTC0yMDAwLTE3NC5odG1sDQorICAgICAgKi8NCisJDQordHJ5X2Fn
> YWluOg0KICAgICBpZiAoLTEgPT0gKGZkID0gYWNjZXB0KGxpc3RlbmVyLT5m
> ZCwgKHN0cnVjdCBzb2NrYWRkciopICZhZGRyLA0KIAkJCSAgICZhZGRybGVu
> KSkpIHsNCisgICAgICAgIA0KKyAgICAgIC8qIFRoZXJlIGlzIG5vIG90aGVy
> IGNvbm5lY3Rpb24gcGVuZGluZyAqLw0KKyAgICAgIGlmIChlcnJubyA9PSBF
> QUdBSU4pDQorICAgICAgICByZXR1cm47DQorDQogICAgICAgLyogTG90c2Eg
> YWRtaW5zIHNlZW0gdG8gaGF2ZSBwcm9ibGVtcyB3aXRoIG5vdCBnaXZpbmcg
> ZW5vdWdoIGZpbGUNCiAgICAgICAgKiBkZXNjcmlwdG9ycyB0byB0aGVpciBz
> ZXJ2ZXIgc28gd2UnbGwgYWRkIGEgZ2VuZXJpYyB3YXJuaW5nIG1lY2hhbmlz
> bQ0KICAgICAgICAqIGhlcmUuICBJZiBpdCB0dXJucyBvdXQgdG9vIG1hbnkg
> bWVzc2FnZXMgYXJlIGdlbmVyYXRlZCBmb3INCiAgICAgICAgKiBtZWFuaW5n
> bGVzcyByZWFzb25zIHdlIGNhbiBmaWx0ZXIgdGhlbSBiYWNrLg0KICAgICAg
> ICAqLw0KICAgICAgIHNlbmR0b19vcG1hc2tfYnV0b25lKDAsIFNOT19UQ1BD
> T01NT04sDQotCQkJICAgIlVuYWJsZSB0byBhY2NlcHQgY29ubmVjdGlvbjog
> JW0iKTsNCisJCQkgICAiVW5hYmxlIHRvIGFjY2VwdCBjb25uZWN0aW9uOiAl
> cyIsIHN0cmVycm9yKGVycm5vKSk7DQogICAgICAgcmV0dXJuOw0KICAgICB9
> DQogICAgIC8qDQpAQCAtNDg1LDUgKzUwMSw2IEBADQogLyogICAgICBuZXh0
> cGluZyA9IEN1cnJlbnRUaW1lOyAqLw0KIA0KICAgICBhZGRfY29ubmVjdGlv
> bi
[Coder-Com] Re: [Patches] Adding multi-accept
> I noticed that some of the temporary error conditions will exit the
> function. You might want to consider using continues in the while
> form.
Thanks for pointing this out.
If the IRC server is configured for low load situations, I'd
prefer not rejecting connections and thus return from the
function. For the remaining two checks, it makes sense to
use continue. I've expanded the comments where appropiate.
> I'm afraid I won't accept anything that uses goto except in
> error exit conditions in functions that need to do cleanups due to
> stylistic prejudices.
Yes, therefore the submission of two patches (-no-goto).
> I have a slight concern about
> indentation, so you might want to look at that, but it's relatively
> minor, as I could correct it when I commit.
That would be appreciated. I found no style guide and have
thus relied on vim with tabstop=4,shiftwidth=2,expandtab.
- Sascha Experience IRCG
http://schumann.cx/http://schumann.cx/ircg
Index: listener.c
===
RCS file: /home/coder-com/cvs/ircu2.10/ircd/listener.c,v
retrieving revision 1.17.2.1
diff -u -r1.17.2.1 listener.c
--- listener.c 2002/01/11 00:20:32 1.17.2.1
+++ listener.c 2002/05/17 17:30:02
@@ -442,48 +442,70 @@
* point, just assume that connections cannot
* be accepted until some old is closed first.
*/
-if (-1 == (fd = accept(listener->fd, (struct sockaddr*) &addr,
- &addrlen))) {
- /* Lotsa admins seem to have problems with not giving enough file
- * descriptors to their server so we'll add a generic warning mechanism
- * here. If it turns out too many messages are generated for
- * meaningless reasons we can filter them back.
+
+ /*
+ * This piece of code implements multi-accept, based
+ * on the idea that poll/select can only be efficient,
+ * if we succeed in handling all available events,
+ * i.e. accept all pending connections.
+ *
+ * http://www.hpl.hp.com/techreports/2000/HPL-2000-174.html
+ */
+
+while (1) {
+ if (-1 == (fd = accept(listener->fd, (struct sockaddr*) &addr,
+ &addrlen))) {
+
+/* There is no other connection pending */
+if (errno == EAGAIN || errno == EWOULDBLOCK)
+ return;
+
+/* Lotsa admins seem to have problems with not giving enough file
+ * descriptors to their server so we'll add a generic warning mechanism
+ * here. If it turns out too many messages are generated for
+ * meaningless reasons we can filter them back.
+ */
+sendto_opmask_butone(0, SNO_TCPCOMMON,
+"Unable to accept connection: %m");
+return;
+ }
+ /*
+ * check for connection limit. If this fd exceeds the limit,
+ * all further accept()ed connections will also exceed it.
+ * Enable the server to clear out other connections before
+ * continuing to accept() new connections.
*/
- sendto_opmask_butone(0, SNO_TCPCOMMON,
- "Unable to accept connection: %m");
- return;
-}
-/*
- * check for connection limit
- */
-if (fd > MAXCLIENTS - 1) {
- ++ServerStats->is_ref;
- send(fd, "ERROR :All connections in use\r\n", 32, 0);
- close(fd);
- return;
-}
-/*
- * check to see if listener is shutting down
- */
-if (!listener->active) {
- ++ServerStats->is_ref;
- send(fd, "ERROR :Use another port\r\n", 25, 0);
- close(fd);
- return;
-}
-/*
- * check to see if connection is allowed for this address mask
- */
-if (!connection_allowed((const char*) &addr,
- (const char*) &listener->mask)) {
- ++ServerStats->is_ref;
- send(fd, "ERROR :Use another port\r\n", 25, 0);
- close(fd);
- return;
-}
-++ServerStats->is_ac;
-/* nextping = CurrentTime; */
+ if (fd > MAXCLIENTS - 1) {
+++ServerStats->is_ref;
+send(fd, "ERROR :All connections in use\r\n", 32, 0);
+close(fd);
+return;
+ }
+ /*
+ * check to see if listener is shutting down. Continue
+ * to accept(), because it makes sense to clear our the
+ * socket's queue as fast as possible.
+ */
+ if (!listener->active) {
+++ServerStats->is_ref;
+send(fd, "ERROR :Use another port\r\n", 25, 0);
+close(fd);
+continue;
+ }
+ /*
+ * check to see if connection is allowed for this address mask
+ */
+ if (!connection_allowed((const char*) &addr,
+(const char*) &listener->mask)) {
+++ServerStats->is_ref;
+send(fd, "ERROR :Use another port\r\n", 25,
Re: [Coder-Com] level 500 command proposal
Hello Cosmin, Friday, May 17, 2002, 2:50:20 PM, you wrote: CM> Hello. CM> Almost everybody knows that if you have sufficient CM> access in a channel to set a ban through X and you set CM> that ban on *!*@*.* X will kick all users from that CM> channel. You need access level >= ban level to remove CM> it. The problem is that the username's password can be CM> stolen. So, with a stolen password and sufficient CM> access you can kick out an entire channel. This CM> sucks... CM> My proposal is to add a new channel setting (level CM> 500). For example FULLBAN (OFF or ON) which allow (or CM> not) users to set bans on *.* . I guess is a good CM> ideea... 10x & please excuse my english. CM> Best regards, CM> JL` CM> __ CM> Do You Yahoo!? CM> LAUNCH - Your Yahoo! Music Experience CM> http://launch.yahoo.com Nice idea, but there is one problem. If you have looked at the mailingarchive you would see this problem has been discussed before and noone seems to care about it. Sounds harsch and is a personal opinion. But likely to be a fact. Stolen usernames are considered a lack of security on the clients side where the user has not put enough efforts into securing his data. Thus in case of a compromised client the client is on his own and needs to act damn quickly in immediately mailing [EMAIL PROTECTED] . The problem that accompanies it that this mailbox receives massive amounts of mail, so before they read it could take a couple of days. My opinion is to completly remove the option to be able to use *!*@* as kick/ban mask. (Run: you stated you would use it to clean up your banlist, so it would only be needed to UNBAN, no need to use it for BAN/KICK in this matter) -- Best regards, Alexandermailto:[EMAIL PROTECTED]
Re: [Coder-Com] level 500 command proposal
2002-05-17 14:50:20, skrev Cosmin Marcu <[EMAIL PROTECTED]>: >Hello. > >Almost everybody knows that if you have sufficient >access in a channel to set a ban through X and you set >that ban on *!*@*.* X will kick all users from that >channel. You need access level >= ban level to remove >it. The problem is that the username's password can be >stolen. As you login you will, as you already know, be notified on NEVER to give out your password. Those who does it, doesn't really pay attention to what the undernet cs has to say about username/channel security. There has been added MAXLOGINS, wich I, and probably many others, look at as enough security. >So, with a stolen password and sufficient >access you can kick out an entire channel. This >sucks... >My proposal is to add a new channel setting (level >500). For example FULLBAN (OFF or ON) which allow (or >not) users to set bans on *.* . I guess is a good >ideea... 10x & please excuse my english. You can do a lot of damage, if you have someone elses usernames. This is a fact that sucks, indeed, but as said earlier, there is honestly enough security for this. : /Snatcher
Re: [Coder-Com] level 500 command proposal
> My proposal is to add a new channel setting (level > 500). For example FULLBAN (OFF or ON) which allow (or > not) users to set bans on *.* . I guess is a good > ideea... 10x & please excuse my english. > How does the IRC daemon know if a ban is a full ban? *!*@* *!*@*.* *!*@*.??? *!~*@* *!*@?*.???* Then of course you can do: *!*@*.?? *!*@*.com *!*@*.net *!*@*.org *!*@*.info etc or, perhaps "a*!*@*", "b*!*@*" they still ban everyone. How do you know if a ban is too wide? -- Cahn's Axiom: When all else fails, read the instructions.
[Coder-Com] IRCd development talk
Hello We are sending this e-mail on behalf of the members who developed the IRC of Irc-Hispano.org, in order to organise the first meeting among the main developers of the IRC of the most important irc networks in the world Our purpose is to organise a debate from time to time in one of those networks in a channel, so that we will comment the last news as for development ideas of future,and the most important thing, to fix a point of communication and mutual collaboration. Taking advantage of the inaguration of our web space at http://www.irc-dev.net we thought of invite all the developers or collaborators of the main networks in the world next Tuesday 21st May, and celebrate this first talk in #irc-dev channel at IRC-Hispano. from 6:00 pm (GMT+2 Paris-Madrid) We propose to use our network cos the idea has born here, but it would be no problem in having the talk in other network if neccesary :) English will be used in the talk. You will be invited to make suggestions, give your opinions and the most important thing, tell us how you work for the development of your network and the ideas you have for the future IRC use Please,confirm,if possible your attendance sending an e-mail to [EMAIL PROTECTED] with the subject:"Talk", and leave your nick We have removed the usual +R mode to the channel to let you come in with any nick without having to register one. Our network runs a "stealth" server that checks some well known ports: 3128, 1080, 8080, 8081, 31337, 12345 and other tipical virus/trojans/proxy ports. Actually, due to a recent trojan for mIRC that uses port 6667 to infect, that port is also included, so please close it (or drop 194.149.72.34 and 194.179.44.5 in your firewall, those IP's are the origin of the scan) We are sorry by that inconvenience. We are looking forward to seeing you in the talk *** Bests regards, Development team of IRC-Hispano at #irc-dev
Re: [Coder-Com] level 500 command proposal
I agree The ability to ban *!*@* should be either (a) limited to cservice staff only, or (b) blocked completely to everyone. In my opinion, 9 times out of 10, a *!*@* ban is considered abusive and probably used to maliciously lock up the channel. I don't really see a need to allow anyone to ban *!*@*, so I believe it should be limited to cservice staff only or totally blocked to everybody. But, leave the ability to quickly clear the X banlist by unbanning *!*@*. > > Nice idea, but there is one problem. If you have looked at the > mailingarchive you would see this problem has been discussed before > and noone seems to care about it. Sounds harsch and is a personal > opinion. But likely to be a fact. > Stolen usernames are considered a lack of security on the clients side > where the user has not put enough efforts into securing his data. Thus > in case of a compromised client the client is on his own and needs to > act damn quickly in immediately mailing [EMAIL PROTECTED] . > The problem that accompanies it that this mailbox receives massive > amounts of mail, so before they read it could take a couple of days. > > My opinion is to completly remove the option to be able to use *!*@* > as kick/ban mask. (Run: you stated you would use it to clean up your banlist, so it > would only be needed to UNBAN, no need to use it for BAN/KICK in this > matter) > > > -- > Best regards, > Alexandermailto:[EMAIL PROTECTED] > > >
Re: [Coder-Com] level 500 command proposal
Regarding *!*@*.* see Isomer's email. There IS enough security. Regarding what to do when your username is hacked on undernet... First, go to http://cservice.undernet.org/live/ login (if you still can) and change your password, if you cannot login, use forgotten password (link both in side bar and right below where to login). Failing those to options, email [EMAIL PROTECTED], if still no help, then as a last resort try [EMAIL PROTECTED] [EMAIL PROTECTED] only comes into the picture when you see someone else's username is hacked and being abused. (and even then this should be verified by asking in #CService) (Please give all email addresses 5 days to reply, if no reply after 5 days resend the email) Regards [EMAIL PROTECTED] Official CService Admin On 18/5/02 4:55, "Alexander Maassen" <[EMAIL PROTECTED]> wrote: > Hello Cosmin, > > Friday, May 17, 2002, 2:50:20 PM, you wrote: > > CM> Hello. > > CM> Almost everybody knows that if you have sufficient > CM> access in a channel to set a ban through X and you set > CM> that ban on *!*@*.* X will kick all users from that > CM> channel. You need access level >= ban level to remove > CM> it. The problem is that the username's password can be > CM> stolen. So, with a stolen password and sufficient > CM> access you can kick out an entire channel. This > CM> sucks... > CM> My proposal is to add a new channel setting (level > CM> 500). For example FULLBAN (OFF or ON) which allow (or > CM> not) users to set bans on *.* . I guess is a good > CM> ideea... 10x & please excuse my english. > > CM> Best regards, > CM> JL` > > > CM> __ > CM> Do You Yahoo!? > CM> LAUNCH - Your Yahoo! Music Experience > CM> http://launch.yahoo.com > > Nice idea, but there is one problem. If you have looked at the > mailingarchive you would see this problem has been discussed before > and noone seems to care about it. Sounds harsch and is a personal > opinion. But likely to be a fact. > Stolen usernames are considered a lack of security on the clients side > where the user has not put enough efforts into securing his data. Thus > in case of a compromised client the client is on his own and needs to > act damn quickly in immediately mailing [EMAIL PROTECTED] . > The problem that accompanies it that this mailbox receives massive > amounts of mail, so before they read it could take a couple of days. > > My opinion is to completly remove the option to be able to use *!*@* > as kick/ban mask. (Run: you stated you would use it to clean up your banlist, > so it > would only be needed to UNBAN, no need to use it for BAN/KICK in this > matter) >
Re: [Coder-Com] level 500 command proposal
banning *!*@* has some advantages. When you ban *!*@* from a channel, only voiced and opped people will be able to talk, to change their nicks, and no one will be able to join. In chans like #class, it's sometimes useful to have that ban enabled. Anyway, if someone wishes to lock a chan, he can +sntmilk and kick everyone. Theres no need to remove the possibility to ban *!*@*. It's up to the manager to choose his ops. And like Isomer said, it's hard to determine what is too wide. I think we should just forget about making changes on banning *!*@*. regards, Hidden - Original Message - From: "Dave C." <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Friday, May 17, 2002 5:16 PM Subject: Re: [Coder-Com] level 500 command proposal > I agree The ability to ban *!*@* should be either (a) limited to > cservice staff only, or (b) blocked completely to everyone. > In my opinion, 9 times out of 10, a *!*@* ban is considered abusive and > probably used to maliciously lock up the channel. > I don't really see a need to allow anyone to ban *!*@*, so I believe it > should be limited to cservice staff only or totally blocked to everybody. > But, leave the ability to quickly clear the X banlist by unbanning *!*@*. > > > > > Nice idea, but there is one problem. If you have looked at the > > mailingarchive you would see this problem has been discussed before > > and noone seems to care about it. Sounds harsch and is a personal > > opinion. But likely to be a fact. > > Stolen usernames are considered a lack of security on the clients side > > where the user has not put enough efforts into securing his data. Thus > > in case of a compromised client the client is on his own and needs to > > act damn quickly in immediately mailing [EMAIL PROTECTED] . > > The problem that accompanies it that this mailbox receives massive > > amounts of mail, so before they read it could take a couple of days. > > > > My opinion is to completly remove the option to be able to use *!*@* > > as kick/ban mask. (Run: you stated you would use it to clean up your > banlist, so it > > would only be needed to UNBAN, no need to use it for BAN/KICK in this > > matter) > > > > > > -- > > Best regards, > > Alexandermailto:[EMAIL PROTECTED] > > > > > > > > >
