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@lists.dal.net>wrote:

Send DALnet-services mailing list submissions to dalnet-services@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@lists.dal.net

You can reach the person managing the list at dalnet-services-owner@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@yahoo.com> Subject: [DALnet-services] RFC Services Access and Bahamut Interaction To: dalnet-services@lists.dal.net Message-ID: <135821.36367.qm@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@lists.dal.net https://lists.dal.net/mailman/listinfo/dalnet-services

End of DALnet-services Digest, Vol 7, Issue 1 *********************************************