[Mageia-sysadm] Usernames, uids, and groups

[Buchan Milne]

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 
appropriate.

Regards,
Buchan