[Mageia-sysadm] Usernames, uids, and groups

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 
+appropriate.
+
+Regards,
+Buchan
+