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
*********************************************