December 2009 - DALnet-services

RFC Services Access and Bahamut Interaction
by PapaSmurf 06 Jan '10

06 Jan '10

I thought I'd give this mailing list a much-needed kickstart. More coming to the helpers mailing list after Christmas (maybe after new years). This is meant to be an unofficial RFC (request for comments) pertaining to the information posted here, so post away. ;p TOPIC: ChanServ/NickServ access and Bahamut/Services interaction. OBJECTIVE: Potential enhancements to be explored by services coders, and to provide helpers with information. * NickServ Access NickServ ACC 3 = Nick is ID'd to NickServ NickServ ACC 2 = Nick matches an access entry NickServ ACC 1 = Nick is registered NickServ ACC 0 = Nick is not registered Special thanks to " phnx " for providing the following info for NickServ ACC 1... Either the person using the nick isn't the owner, or the owner is using it and they registered the nick before Jan 1, 2003 (and they never turned Enforce On). The owner, under this scenario, had to AUTH via the web link (not through services). Else, the nick had to be registered before Jan 1, 2000 (when AUTH wasn't around), and never set Enforce On. * ChanServ Access ChanServ ACC 5 = Founder access via ChanServ identification ChanServ ACC 4 = Founder access via NickServ identification ChanServ ACC 3 = Founder access via Founder access entry ChanServ ACC 2 = Channel SOp, or matches an SOp access entry ChanServ ACC 1 = Channel AOp, or matches an AOp access entry ChanServ ACC 0 = All Other users/channel guests ChanServ ACC -1 = Akick'd users ChanServ ACC -2 = Channel has been Frozen or Closed * NickServ Access Entries Adding access entries (to channel founder, SOp and AOp nicknames) has many implications to proper channel management and security. ChanServ ACC 3/2/1 can be obtained by matching AOp or above access entries. SECTION 1: GENERALITIES * Ident > Access Matches > OpGuard 1.1 The ChanServ Ident feature is set on, by default, upon new channel registrations for very good reasons. This does two things: a. It negates access matches (and potential problems for channel managers/founders). b. It negates ChanServ's Unsecure feature (which requires access matches to function). 1.2 The ChanServ OpGuard (Secured Ops) feature is negated by access matches (ChanServ ACC 3/2/1). Only Ident can negate access matches; not OpGuard. 1.3 The ChanServ Unsecure feature is superceeded by Ident, and has no bearing on OpGuard. With Ident off, unsecure does nothing more than what access matches do by themselves. Basically, unsecure is now obsolete. SECTION 2: OP LISTS & ACCESS RULES 2.1 Only founder can be added to two op lists (by nickname only). Founder and AOp or SOp list. If the founder wants to be on all 3 lists, they must be added by address to the third. AOps and SOps can only be on one list by nickname. To be on both AOp/SOp lists, the second list must be added by address. 2.2 Access Rules 2.2.1 ChanServ Ident must be switched off for access matches to function. 2.2.2 Founders (ChanServ ACC 5/4/3) can be akick'd, but AOps/SOps cannot. ChanServ ACC 3 founders can ADD/DEL SOps. 2.2.3 AOps/SOps cannot be added if their nick/address is on the akick list. 2.2.4 Akicks (ChanServ ACC -1) can be bypassed if the akick'd matches founder/SOp/AOp access entry (or they are founder). Akick'd users can send channel memos (as long as they match the memo level set for the channel). 2.2.5 Founders can be akick'd by anyone with an access of ChanServ ACC -1 or higher (5/4/3/2/1/0/-1) as long as they match any SOp or higher's (ACC 5/4/3/2) access list. Note: Must be SOp or higher to add/del akicks. =============================================================== Services Coders: With the above rules, how about making new channel registrants (founders) automatically added to the SOp list (as well as being named founder). Why? 1. SOps cannot add the founder to the akick list (because the founder is on the SOp list). 2. Adding founder to the AOp list is pointless; SOps can delete the AOp entry then akick the founder at will. 3. If the founder wants off the SOp list (to use his/her 100 max SOp-entry quota) they can do so after channel registration. 4. If founder is the founder, what would it matter if the founder is akick'd? ANSWER: The founder changes founder name, but still uses the original founder name (to visit the channel). The new founder doesn't have an access entry (or Ident could be on). SOp adds the original founder nick to akick. Founder, using original founder nick, gets banned upon re-entry into the channel. Ultimately, founders get a truer sense of being top dog (without the hassle of adding their other ID to the SOp list). =============================================================== 2.2.6 With Ident switched on, ChanServ ACC 3 doesn't exist. SECTION 3: UNREGISTERED CHANNEL FOUNDERS (NICKSERV ACC 0) 3.1 In the "eyes" of services (ChanServ/NickServ), a dropped nick is the same as an expired nick. 3.2 A founder purposely drops his founder nick. He/she will continue to have ChanServ ACC 5 as long as: A) they do not log off DALnet B) Successor doesn't take over C) anyone else doesn't set themself as founder. 3.3 Such a founder can do all channel-related management they could before with two exceptions: A) They cannot send channel memos (a registered nick is required to send/read memos). B) They cannot drop the channel (ChanServ memos the drop code). 3.4 They can bypass Ident/Restrict/Opguard/etc features. SECTION 4: BAHAMUT IRCD/SERVICES INTERACTIONS 4.1 Not much is known of the interation between services and bahamut IRCd. I believe this matter needs to be explored more by helpers/coders, and the information needs to be shared (on this mailing list, or by updating http://docs.dal.net/ with proper information). 4.2 Examples of interactions: 4.2.1 ChanServ mkick and channel excepts. Excepts (channel mode +e) are designed to allow people in who match a large ban set (from abusive users, etc). If a guest is on the except list and an mkick is issued (by the highest ranking op on the channel), guess who ChanServ doesn't kick? Right, the guest. Mass kick does not unset excepts, and allows excepts to remain in the channel throughout the mass kick process. 4.2.2 ChanServ restrict and channel excepts. When a restricted channel has a violation (a non AOp/SOp/Founder joins), and an except is set, ChanServ will join the channel and unset the excepts before removing the guest. 4.3 Excepts, like all channel modes, are IRCd command features. The bond bahamut and services share is more apparent than what we think we know. This avenue needs to be explored more. Maybe we can get this mailing list kickstarted with said chatter (pertaining to findings resulting from testing any and all interactions). Well, happy holidays to all. tchin tchin! PapaSmurf

6 16

HelpServ Overhaul - RFC (request for comments)
by PapaSmurf 01 Jan '10

01 Jan '10

Obviously the information in HelpServ is obsolete. Just a few commands I find even remotely useful for helping new users to DALnet... 1. /helpserv rules 2. /helpserv basics 3. /helpserv etiquette I made a post to the helpers@ mailing list with Bahamut IRCd commands for non-oper users. Maybe we could revamp /helpserv basics with taht information. I went to #bahamut weeks ago, and a channel op there said he didn't know of an existing Bahamut IRCd command list to reference (hence the reason I posted it). Maybe we can revamp HelpServ to use as a reference tool (with relevant topics) for help channel staff to reference newbies to. Some topic examples... /helpserv welcome - Welcome msg from DALnet /helpserv listhelp - list of help channels /helpserv register - nick/chan registration benefits /helpserv vhosts - DALnet doesn't have a HostServ, but BNC... /helpserv threats - if threatened, what to do (contacts?) /helpserv services - Differentiate DALnet from other networks Note: With the services topic, such things as no halfops, botserv, X, etc. /helpserv banned - basic information to check who banned & how to msg... Note: with the banned topic, maybe stuff like... /mode #channel b to see who banned them, and /whois to see what their addy is, etc. I'd like to see some posts to this thread with other examples. Maybe we can all talk the services coders into revamping the obsolete service. Still, I find it useful, and it should not be phased out. I would be more than happy to donate my time in writing samples to submit to this mailing list for RFCs. Together, we can get working topics compiled and update HelpServ. PapaSmurf

3 3

dalnet-services@ observations
by PapaSmurf 31 Dec '09

31 Dec '09

Kobi: Thanks for the reply to the post. I replied, and thought it went to the mailing list. Everyone: I started playing with NS/CS access one day and found some peculiarities. Kobi and DALnet now know of them, and I am pleased. Hopefully the bugs I pointed out will be fixed for the next services release. I posted to the helpers@ mailing list yesterday, and I found that the initial to welcome message from dalnet hasn't been updated since 1996. At the beginning of the email, it says to post to the helpers list, to mail to Helpers(a)lists.dal.net -- Well, you will get the email sent back; only helpers(a)lists.dal.net (lowercase h) works. I am not sure if dalnet-services@ is the same way, but the same syntax is there... Welcome to the DALnet-services(a)lists.dal.net mailing list! Anyway, I hope we can generate more threads here. I believe there is a lot to discuss (to make services better). Myself, I'd like to see HelpServ completely overhauled. The information within is way too obsolete... Maybe I will start a thread next about it. Stay tuned. ;) As for the rest of you, start posting some threads on the general mailing lists. We are here to make DALnet better; to discuss possible improvements. PapaSmurf

5 5

Re: DALnet-services Digest, Vol 7, Issue 1
by Houmood Abdulrahman 29 Dec '09

29 Dec '09

hello .. i like this topic and i want to add something for it.. like C-Founder access .. which can delete sop and edit description and mlock ..etc try to thinking about this access it is so nice :D regards. -darkelf. On Sun, Dec 27, 2009 at 11:00 PM, <dalnet-services-request(a)lists.dal.net>wrote: > Send DALnet-services mailing list submissions to > dalnet-services(a)lists.dal.net > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.dal.net/mailman/listinfo/dalnet-services > or, via email, send a message with subject or body 'help' to > dalnet-services-request(a)lists.dal.net > > You can reach the person managing the list at > dalnet-services-owner(a)lists.dal.net > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of DALnet-services digest..." > > > Today's Topics: > > 1. RFC Services Access and Bahamut Interaction (PapaSmurf) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Fri, 18 Dec 2009 09:05:17 -0800 (PST) > From: PapaSmurf <freedried(a)yahoo.com> > Subject: [DALnet-services] RFC Services Access and Bahamut Interaction > To: dalnet-services(a)lists.dal.net > Message-ID: <135821.36367.qm(a)web62107.mail.re1.yahoo.com> > Content-Type: text/plain; charset=us-ascii > > I thought I'd give this mailing list a much-needed kickstart. More coming > to the > helpers mailing list after Christmas (maybe after new years). > > This is meant to be an unofficial RFC (request for comments) pertaining to > the information > posted here, so post away. ;p > > > > TOPIC: ChanServ/NickServ access and Bahamut/Services interaction. > > OBJECTIVE: Potential enhancements to be explored by services coders, and to > provide > helpers with information. > > > > * NickServ Access > > > NickServ ACC 3 = Nick is ID'd to NickServ > NickServ ACC 2 = Nick matches an access entry > NickServ ACC 1 = Nick is registered > NickServ ACC 0 = Nick is not registered > > Special thanks to " phnx " for providing the following info for NickServ > ACC 1... > > Either the person using the nick isn't the owner, or the owner is using it > and they > registered the nick before Jan 1, 2003 (and they never turned Enforce On). > The owner, > under this scenario, had to AUTH via the web link (not through services). > Else, the > nick had to be registered before Jan 1, 2000 (when AUTH wasn't around), and > never set > Enforce On. > > > > * ChanServ Access > > > ChanServ ACC 5 = Founder access via ChanServ identification > ChanServ ACC 4 = Founder access via NickServ identification > ChanServ ACC 3 = Founder access via Founder access entry > ChanServ ACC 2 = Channel SOp, or matches an SOp access entry > ChanServ ACC 1 = Channel AOp, or matches an AOp access entry > ChanServ ACC 0 = All Other users/channel guests > ChanServ ACC -1 = Akick'd users > ChanServ ACC -2 = Channel has been Frozen or Closed > > > > * NickServ Access Entries > > > Adding access entries (to channel founder, SOp and AOp nicknames) has many > implications > to proper channel management and security. ChanServ ACC 3/2/1 can be > obtained by > matching AOp or above access entries. > > > > > SECTION 1: GENERALITIES > > > * Ident > Access Matches > OpGuard > > > 1.1 The ChanServ Ident feature is set on, by default, upon new channel > registrations > for very good reasons. This does two things: > > a. It negates access matches (and potential problems for channel > managers/founders). > b. It negates ChanServ's Unsecure feature (which requires access matches to > function). > > > 1.2 The ChanServ OpGuard (Secured Ops) feature is negated by access matches > (ChanServ ACC 3/2/1). Only Ident can negate access matches; not OpGuard. > > > 1.3 The ChanServ Unsecure feature is superceeded by Ident, and has no > bearing on > OpGuard. With Ident off, unsecure does nothing more than what access > matches do by > themselves. Basically, unsecure is now obsolete. > > > > > SECTION 2: OP LISTS & ACCESS RULES > > > 2.1 Only founder can be added to two op lists (by nickname only). Founder > and AOp or > SOp list. If the founder wants to be on all 3 lists, they must be added by > address to > the third. AOps and SOps can only be on one list by nickname. To be on both > AOp/SOp > lists, the second list must be added by address. > > > > 2.2 Access Rules > > > 2.2.1 ChanServ Ident must be switched off for access matches to function. > > 2.2.2 Founders (ChanServ ACC 5/4/3) can be akick'd, but AOps/SOps cannot. > ChanServ > ACC 3 founders can ADD/DEL SOps. > > 2.2.3 AOps/SOps cannot be added if their nick/address is on the akick list. > > 2.2.4 Akicks (ChanServ ACC -1) can be bypassed if the akick'd matches > founder/SOp/AOp > access entry (or they are founder). Akick'd users can send channel memos > (as long as > they match the memo level set for the channel). > > 2.2.5 Founders can be akick'd by anyone with an access of ChanServ ACC -1 > or higher > (5/4/3/2/1/0/-1) as long as they match any SOp or higher's (ACC 5/4/3/2) > access list. > > Note: Must be SOp or higher to add/del akicks. > > > =============================================================== > Services Coders: > > With the above rules, how about making new channel registrants (founders) > automatically > added to the SOp list (as well as being named founder). Why? > > 1. SOps cannot add the founder to the akick list (because the founder is on > the SOp list). > > 2. Adding founder to the AOp list is pointless; SOps can delete the AOp > entry then akick > the founder at will. > > 3. If the founder wants off the SOp list (to use his/her 100 max SOp-entry > quota) they > can do so after channel registration. > > 4. If founder is the founder, what would it matter if the founder is > akick'd? > > ANSWER: The founder changes founder name, but still uses the original > founder name (to > visit the channel). The new founder doesn't have an access entry (or Ident > could be on). > SOp adds the original founder nick to akick. Founder, using original > founder nick, gets > banned upon re-entry into the channel. Ultimately, founders get a truer > sense of being > top dog (without the hassle of adding their other ID to the SOp list). > =============================================================== > > > 2.2.6 With Ident switched on, ChanServ ACC 3 doesn't exist. > > > > > SECTION 3: UNREGISTERED CHANNEL FOUNDERS (NICKSERV ACC 0) > > > 3.1 In the "eyes" of services (ChanServ/NickServ), a dropped nick is the > same as an > expired nick. > > 3.2 A founder purposely drops his founder nick. He/she will continue to > have ChanServ > ACC 5 as long as: A) they do not log off DALnet B) Successor doesn't take > over > C) anyone else doesn't set themself as founder. > > 3.3 Such a founder can do all channel-related management they could before > with two > exceptions: > > A) They cannot send channel memos (a registered nick is required to > send/read memos). > B) They cannot drop the channel (ChanServ memos the drop code). > > 3.4 They can bypass Ident/Restrict/Opguard/etc features. > > > > > SECTION 4: BAHAMUT IRCD/SERVICES INTERACTIONS > > > 4.1 Not much is known of the interation between services and bahamut IRCd. > I believe > this matter needs to be explored more by helpers/coders, and the > information needs to > be shared (on this mailing list, or by updating http://docs.dal.net/ with > proper > information). > > 4.2 Examples of interactions: > > 4.2.1 ChanServ mkick and channel excepts. > > Excepts (channel mode +e) are designed to allow people in who match a large > ban set > (from abusive users, etc). If a guest is on the except list and an mkick is > issued > (by the highest ranking op on the channel), guess who ChanServ doesn't > kick? Right, > the guest. Mass kick does not unset excepts, and allows excepts to remain > in the > channel throughout the mass kick process. > > 4.2.2 ChanServ restrict and channel excepts. > > When a restricted channel has a violation (a non AOp/SOp/Founder joins), > and an except > is set, ChanServ will join the channel and unset the excepts before > removing the guest. > > 4.3 Excepts, like all channel modes, are IRCd command features. The bond > bahamut and > services share is more apparent than what we think we know. This avenue > needs to be > explored more. Maybe we can get this mailing list kickstarted with said > chatter > (pertaining to findings resulting from testing any and all interactions). > > > > > Well, happy holidays to all. tchin tchin! > > > PapaSmurf > > > > > > ------------------------------ > > _______________________________________________ > DALnet-services mailing list > DALnet-services(a)lists.dal.net > https://lists.dal.net/mailman/listinfo/dalnet-services > > > End of DALnet-services Digest, Vol 7, Issue 1 > ********************************************* >

1 0