View Issue Details

IDProjectCategoryView StatusLast Update
0002141unrealdocumentationpublic2004-11-05 16:42
ReporterStealth Assigned Tocodemastr 
PrioritynormalSeveritytrivialReproducibilityalways
Status resolvedResolutionfixed 
Fixed in Version3.2.3 
Summary0002141: Document default snomask behavior
DescriptionIt seems that sometimes the snomasks in oper::snomak override the ones in set::snomask-on-oper. Other times, it seems to just add the snomasks from oper::snomask to set::snomask-on-oper.

With the oper blocks I have tried this with, the first one (Stealth) in the file will override set::snomask-on-oper, and the second (ProxyScanner) will add to set::snomask-on-oper.

The 2 oper blocks I have this happen to are in the additional indormation. I do not know if this is intentional, or a bug. I have also not asked anyone if they can reproduce it on their own IRCd.
Additional Informationoper Stealth {
        class clients;
        from {
                userhost *@192.168.1.*;
                userhost ~-@*;
        };
        password "password";
        flags {
                netadmin;
                can_addline;
                can_die;
                can_gkline;
                can_gzline;
                can_override;
                can_restart;
                can_zline;
                get_umodew;
        };
        snomask cFfkevGqsSUo;
        modes gsHpq;
};


oper ProxyScanner {
        class clients;
        from { userhost *@127.0.0.*; };
        password "password";
        flags { global; };
        modes sBDHp;
        snomask cF;
};
TagsNo tags attached.
3rd party modules

Activities

aquanight

2004-10-28 01:27

reporter   ~0008138

And set::snomask-on-oper is?

Stealth

2004-10-28 01:31

reporter   ~0008139

snomask-on-oper "+cfkvGqsSo";

aquanight

2004-10-28 01:32

reporter   ~0008140

And what snomasks do each wind up with after oper? :P

Stealth

2004-10-28 01:33

reporter   ~0008141

ProxyScanner:
Modes: +iowghsxBHpD +kcfFvGqso

Stealth:
Modes: +iowghraAsxNWqHtp +kcfFveGqSsoU

aquanight

2004-10-28 01:40

reporter   ~0008142

Ok, well for proxy scanner...

cF + cfkvGqsSo should = cfFkvGqsSo (though it's missing S, I wonder if that was unset afterwards)

And for you...

cFfkevGqsSUo + cfkvGqsSo = cfFkevGqsSUo - no change more-or-less.

So aside from proxyscanner missing +S, I can't see the problem. Try removing an snomask from your oper block (that is in the set::snomasks-on-oper) and see if it still gets set.

Stealth

2004-10-28 01:46

reporter   ~0008143

Removed all but esS

My modes:
Modes: +iowghraAsxNWqHtp +eSs

Stealth

2004-10-28 02:10

reporter   ~0008144

After some playing around, I have determined it is because ProxyScanner connects from localhost.

When I added another userhost to the oper block and connected myself, the snomask was overriden by the oper block. I connected from my own computer, which is 192.168.1.103.

Here is the oper block modification:

oper ProxyScanner {
        class clients;
        from { userhost *@127.0.0.*; userhost *; };
        password "password";
        flags { global; };
        snomask scF;
        modes sBDHp;
};

And my result modes when opering with that oper block:
Modes: +iowghsxBHpD +cFs

aquanight

2004-10-28 02:35

reporter   ~0008145

Hm, odd. The only code I can find that sets snomasks (in m_oper) is:
        if (aconf->snomask)
            set_snomask(sptr, aconf->snomask);
        else
            set_snomask(sptr, OPER_SNOMASK);

which implies that oper::snomask SHOULD override set::snomasks-on-oper... so why it appended as described is unclear...

codemastr

2004-10-28 15:57

reporter   ~0008151

I'm guessing this is a module related issue or a feature of your proxy scanner, since, as aquanight pointed out, Unreal either sets from the default, or from the oper::snomask. There is no way it can combine the two. My most likely guess is the proxy scanner is itself sending a MODE command to add the other snomasks. Enable the proxy scanner's debug output and watch to see what it is sending.

Stealth

2004-10-28 16:50

reporter   ~0008156

I have found out why.

It was BOPM setting the modes itself. If the mode directive in the conf is left out, then bopm defaults to setting +sc. When setting just +s, it seems the IRCd gives you a default snomask. I do not know where the default snomask comes from.

You may close this bug if you wish.

codemastr

2004-10-28 22:28

reporter   ~0008159

It is a hardcoded value (well 2 values, one for opers, one for users).

Stealth

2004-10-28 22:53

reporter   ~0008161

Perhaps the hard-coded value and the behavior be added to section 3.3 of the docs?

codemastr

2004-11-05 16:42

reporter   ~0008259

Added in .173

Issue History

Date Modified Username Field Change
2004-10-28 01:18 Stealth New Issue
2004-10-28 01:27 aquanight Note Added: 0008138
2004-10-28 01:31 Stealth Note Added: 0008139
2004-10-28 01:32 aquanight Note Added: 0008140
2004-10-28 01:33 Stealth Note Added: 0008141
2004-10-28 01:40 aquanight Note Added: 0008142
2004-10-28 01:46 Stealth Note Added: 0008143
2004-10-28 02:10 Stealth Note Added: 0008144
2004-10-28 02:35 aquanight Note Added: 0008145
2004-10-28 15:57 codemastr Note Added: 0008151
2004-10-28 16:50 Stealth Note Added: 0008156
2004-10-28 22:28 codemastr Note Added: 0008159
2004-10-28 22:53 Stealth Note Added: 0008161
2004-10-29 15:05 codemastr Category ircd => documentation
2004-10-29 15:05 codemastr Summary oper:snomask set::snomask-on-oper override => Document default snomask behavior
2004-10-29 15:05 codemastr Status new => assigned
2004-10-29 15:05 codemastr Assigned To => codemastr
2004-11-05 16:42 codemastr Status assigned => resolved
2004-11-05 16:42 codemastr Fixed in Version => 3.2.3
2004-11-05 16:42 codemastr Resolution open => fixed
2004-11-05 16:42 codemastr Note Added: 0008259
2006-05-18 17:11 syzop Relationship added related to 0002581
2006-05-18 17:12 syzop Relationship deleted related to 0002581