Commit graph

24 commits

Author SHA1 Message Date
Ed Kellett
b143f5e3bd
m_grant: match "deoper" case-insensitively 2019-09-15 00:35:55 +01:00
Ed Kellett
ebd0f4db7a
m_grant: remove a confusing line 2019-09-15 00:35:55 +01:00
Ed Kellett
7f373431d0
m_grant: use AV2 2019-09-15 00:35:55 +01:00
Ed Kellett
910f883959
m_grant: propagate privset changes 2019-09-15 00:35:55 +01:00
Ed Kellett
bdc87b5f37
m_grant: maintain privilegeset refcounts 2019-09-15 00:35:55 +01:00
Ed Kellett
6119faa9a0
charybdise m_grant 2019-09-15 00:35:55 +01:00
Ed Kellett
c1649fd04d
Use the m_grant from ircd-seven
Charybdis' rewritten m_grant introduces at least one serious bug without
providing any apparent benefit. I think the best solution here is the
easiest one.

The bug in question is that an empty mode change is triggered after
seven's grant has done its work, and this is necessary in order to
give umodes granted by oper privileges a chance to update. The rewrite
removes this, generating a mode change only if it wants to change the
state of +o, which means the grant victim can keep privileged modes they
no longer have access to, or fail to gain new ones.
2019-09-15 00:35:55 +01:00
Ed Kellett
ed3ca2ff16
Propagate OPER
Move opername and privset storage to struct User, so it can exist for
remote opers.

On /oper and when bursting opers, send:

    :foo OPER opername privset

which sets foo's opername and privset. The contents of the privset on
remote servers come from the remote server's config, so the potential
for confusion exists if these do not match.

If an oper's privset does not exist on a server that sees it, it will
complain, but create a placeholder privset. If the privset is created by
a rehash, this will be reflected properly.

/privs is udpated to take an optional argument, the server to query, and
is now local by default:

    /privs [[nick_or_server] nick]
2019-09-13 10:08:27 +01:00
Xenthys
89aef424e9 m_grant.c - fixed remote grant support 2016-09-10 17:54:13 +02:00
William Pitcock
f8f5ff705a m_grant: convert jevolk's rewritten version to AV2 2016-08-05 23:37:05 -05:00
Jason Volk
17f925817e m_grant: rewrite. 2016-07-26 22:40:26 -07:00
Elizabeth Myers
3c7d6fcce7 Message handlers should return void.
Also fix up some return values and stuff to use bool (or void if
nothing). I just did it whilst I was here.

According to jilles, the return value used to signify whether or not the
client had exited. This was error-prone and was fixed a long, long time
ago, but the return value was left int for historical reasons.

Since the return type is not used (and has no clear use case anyway),
it's safe to just get rid of it.
2016-03-09 01:37:03 -06:00
Elizabeth Myers
eeabf33a7c Move module description headers to the top
This is cleaner.

Note this was broken out of a much larger piece of work I did, so if
there's any problems, I apologise!
2016-03-09 01:29:41 -06:00
Elizabeth Myers
9fd8e7cbc9 Do AV2 strings for m_[d-h]* 2016-03-07 01:59:08 -06:00
Elizabeth Myers
105a4985b4 Migrate remaining modules to AV2
No descriptions yet. :(
2016-03-07 00:03:39 -06:00
Elizabeth Myers
cbeab4bc34 Remove $Id tags from everything.
These are obsolete and none have changed since 10 years gao...
2016-03-06 02:47:27 -06:00
William Pitcock
7baa37a9ef msg: remove last vestiges of the fakelag system. charybdis has never supported fakelag. 2016-02-19 16:43:39 -06:00
William Pitcock
428ca87b01 modules: chase MsgBuf API change 2016-02-10 20:54:17 -06:00
William Pitcock
3b1c2aa62c modules: add missing m_grant.c 2016-01-11 23:52:04 -06:00
Elizabeth Jennifer Myers
7eec45bc9d Back out chanroles.
While what chanroles are trying to accomplish is a good idea, it is
apparently unclear this is the proper way to do it. Until we figure out
the exact way we wish to do this, it should be reverted for now.
2011-07-07 21:24:14 -04:00
Elizabeth Jennifer Myers
e1ee78ae30 Partially revert e794d39a80.
As jilles pointed out, it is best that the chanserv access list always
remain synced with the grant list. Thus, the ability for clients to set
this is not a good idea unless services knows about the grant, but this
leads to all sorts of messy issues and likely isn't worth it.
2011-07-06 18:14:57 -04:00
Elizabeth Jennifer Myers
e794d39a80 Add client interface for GRANT.
TODO: implement notifications of grant privilege changes to the target.
2011-07-06 17:25:26 -04:00
William Pitcock
460b6d9fb2 chanroles: ENCAP GRANT should work under the assumption that we want to zero out
this makes setting new roles on a user much easier as we're just setting the roles they
should be having, instead of having to try to revoke roles we don't necessarily know
about.
2011-07-06 15:04:45 -05:00
Elizabeth Jennifer Myers
8aabb973c0 Implement chanroles, as discussed with nenolod.
The theory behind this is that services sends an ENCAP * GRANT #channel
UID :+flagspec message specifying the chanroles the user has. They are
mapped into flag bits and applied to the membership of the user. They
then are restricted or permitted to what they can do based on the
permissions mask regardless of rank.

For backwards compatibility, the default permission bit (without a GRANT
statement) allows a user to to anything an existing op can do ONLY if
they are an op.

Todo: make CHANROLE_STATUS work (the ability to apply +ov to people),
which is at the moment controlled by CHANROLE_MODE.
2011-07-06 13:46:22 -04:00