Ugcs groups
We would like to add functionality where users can create custom groups in both LDAP and AFS with the ability to manage them (similar to the mailman list system already in place).
Contents |
Premise
We want users to have basic group functionality while maintaining security. This seems to imply remctl and shell scripts. The basic commands we want are:
- create a group
- modify group members
- add users individually
- add users en masse
- remove users from a group
- show group members
- delete a group
- show the owner of a group
- show group GID
Group owners should have full control over their list, while others should be able to read the group owner. Sysadmins should be able to bypass checks for group owner status.
Misc. group things
We will need to set aside a block of GID numbers that do not interfere with user groups. The scripts should check to see that the GID they are attempting to create does not exist, and we want a placeholder "last_gid" object to ensure things run smoothly.
LDAP
LDAP groups should be objectClass=posixGroup,ugcsGroup (or some similar) to enable a "ugcsGroupOwner= " attribute. We have an ldap schema block so this shouldn't be too difficult.
The objectClass=ugcsGroup inside of ou=Groups will only be writable by a special user set aside for the purpose. This prevents users from directly using LDAP commands to change group ownership, which would lead to inconsistencies between LDAP and AFS.
The owner information will be only stored in LDAP (see below).
AFS
The biggest security hole is in the AFS part of this software. To create prefix-less AFS groups, such as "spam", the script would have to run as an AFS admin. However, if this keytab were to get compromised a malicious user could have arbitrary power over AFS. To fix this, all groups will be created by a principal "group" and have the form "group:eggs". The "group" principal will own all AFS groups. This prevents users from using AFS commands to change group membership (and thus get LDAP/AFS out of sync).
Implementation
This will work much like the Mailman scripts, with a local script communicating via remctl to a server.
