Permissions handling for network-level commands

[Xe]

Arata needs a common definition of how to restrict commands from other users at the staff level. This is to (for instance) prevent an helper level staff member from forcibly dropping others accounts or killing off Arata.

I propose the following system for permissions handling:

• Users will have a string added to their record representing the permissions group they are in
• A configuration mechanism will be made for checking if a user matches a permission that a command needs
• User accounts must be able to be added and removed from this list at runtime (via a slot in AcidState, etc)
• The first user account registered with Arata will have all staff level permissions

As for permissions I propose the following:

Name	Description
$serv:snoop	ability to see information in $serv that normal users cannot
$serv:manage	ability to make limited changes to functions in $serv
$serv:administer	all permissions

Additionally, a command or subcommand may be allowed by the following:

OperServ:AKILL:ADD

Wildcard matching may also be used.

By default the following groups should be defined:

Name	Permissions
helper	ChanServ:snoop NickServ:snoop OperServ:snoop OperServ:AKILL:ADD
oper	helper, ChanServ:manage NickServ:manage OperServ:manage
admin	oper *:administer

Groups may inherit from other groups and may not contain ":" in their name or contain a capital letter.

Possibly replaces #22 and #21.

[ori-sky]

Thanks for bringing up this issue Xe.

I feel that Arata permissions should be stored per Arata account and should not rely on, nor be affected by, a user's network operator status. I'd like the permissions system to be more generic. This may have been what you were going for but I'd like to outline what I'm thinking for absolute clarity.

Definitions

A key is a verb describing a permission and is comprised of lower-case letters, digits, underscores, and hash symbols (#).

A category is a noun or adjective describing a subset of permissions and is comprised of lower-case letters, digits, underscores, and hash symbols.

A permission is a list of zero or more categories followed by a key and is the fully-qualified name of a permission. These sections comprising a permission are interspersed with colons. Example permissions are as follows:

• die
• ChanServ:die
  • upper-case letters are mapped to lower-case equivalents
• HostServ:vhost:assign

An expression is a permission that has the ability to contain section-scoped wildcard asterisks. For example:

expression	Matches...
NickServ:snoop	the snoop key in only the nickserv category
*:snoop	the snoop key in any category
HostServ:vhost:*	any key in the vhost category of the hostserv category
HostServ:vhost	the vhost category of the hostserv category (i.e. any key)
HostServ	the hostserv category and by extension all sub-categories recursively
*	any category

A group is a symbolic name prefixed by an exclamation mark and comprised of lower-case letters, digits, and underscores. A group contains a list of zero or more groups and expressions.

An account contains a list of zero or more groups and expressions.

[Xe]

I agree with those group and experssion ideas. As far as storing the permissions for users, I think a field should be added to the Account record representing the group name they are in (or Nothing).

For the groups themselves, they should be stored in the database as well. By default Arata should create one group called root that is assigned to the first user registered in Arata. This group will be defined as having all permissions.

Groups should be managed using a command in OperServ. Groups should be documented with their meanings in a subcommand of this command.

How does that look?

[ori-sky]

I was thinking that an account would just have a list of permissions associated with it rather than a single group. This would still allow a group to be added as a permission but would also mean that the first account could simply be given the permission * and that an account could be given multiple group permissions.

I agree that groups should be stored within the database, separately from users, and also that they should be managed using the Arata management service, however I don't know yet if the name of that service will be OperServ or something else.

[Xe]

Ah, that makes sense.

[ori-sky]

Currently I'm resolving the mess that has been given the name Command, but I've assigned resolution of this issue to myself to be carried out once that has been completed.