[Mageia-sysadm] Usernames, uids, and groups
bgmilne at multilinks.com
Tue Nov 9 14:25:51 CET 2010
On Monday, 8 November 2010 17:40:24 Romain d'Alverny wrote:
> On Mon, Nov 8, 2010 at 17:29, nicolas vigier <boklm at mars-attacks.org> wrote:
> > On some machines like the svn server, we need to use pam_ldap to allow
> > users access with their ldap accounts. But on others servers like
> > alamut (web services), or the build nodes, normal users have no reason
> > to login. On those servers, do you think we should restrict access with
> > ssh configuration and a group, or disable pam_ldap completly on those
> > servers and only use local accounts ?
> What would be the risk(s) to use specific ldap groups for that
> purpose? (managing all access in a similar way may be better, no?)
Both have advantages and disadvantages, but the disadvantages for local
accounts increase with N*M (e.g. total number of operations to remove an
old/compromised account), whereas the disadvantages for LDAP increase with N.
where N=number of users and M=number of hosts.
Usually by the time N*M > 50 it becomes difficult to be sure passwords have
been removed everywhere etc.
> > And groups. I think we could use the following groups :
> > * posix : promotes the user as posixAccount+sshPublicKey (in ldap), and
> > allows access to the svn and git using svn+ssh:// and git+ssh://
> > * packager : allows commits in packages repository, package submit using
> > mdvsys, additional permissions on bugzilla, access to the packages
> > maintainers database, etc ...
> > * web : for members of web team, allows commits in web repository
> > * documentation, translator, qa, marketing, etc ... :
> > * packagerapprentice, webapprentice, etc ... : for apprentices, with
> > more restricted access
> > * sysadm : gives admin permissions on all applications
> LDAP groups should as well map team membership. So marketing team guys
> would belong to such a marketingTeam group then.
> > What do you think ?
> We probably won't nail this one in one shot :-)
> As for web, we would need three roles:
> - web-apprentice
> - web (commits to web repos and pushes to tests servers)
> - webmaster (pushes to prod servers)
> We need groups as well for (not exclusive):
> - being a team representative (that is, in the Council)
The current ACLs allow the DN listed in the 'manager' (single-valued)
attribute of a group to modify the member attribute of this group.
Or, do we need these as mailing lists as well?
> - being an association member (eligible and elector)
> - being a board member
> - being the chair(wo)man
> Are group belonging/ownership a "one-time" record or does it get
> archived? (to access a history of past membership). Or should such a
> history be built separately?
Archiving isn't that easy, I would prefer a record to be kept when
More information about the Mageia-sysadm