[Mageia-discuss] Membership handling ( was: Leave )

[Maarten Vanraes]

Op maandag 07 maart 2011 12:34:57 schreef Michael Scherer:
>  On Mon, 7 Mar 2011 12:14:49 +0100, Wolfgang Bornath wrote:
> > 2011/3/7 Michael Scherer <misc at zarb.org>:
> >> This bring the question of account management, ie what should
> >> we do with a account that is explicitely dropped ?
> >> 
> >> Ie :
> >> - disable fully
> >> - leave it as it is now and :
> >>  - disable later
> >>  - leave forever usable
> >> - disable partially ( ie remove from sensitives groups ( and so
> >> define
> >> what group is sensitive ))
> >> 
> >> So what about last proposal ( remove from sensitive group ) and
> >> disable
> >> account
> >> in 6 months / 1 year  ?
> > 
> > +1
> > 
> > We've seen it quite often that people re-discover old interests,
> > hobbies, ex-wives, etc. So, a "sleep time" of 1 year is a good
> > solution.
> > 
> > next thing is to define which are "sensitive groups / access
> > permissions".
> 
>  Depend on the havoc that could be done by someone stealing a unused
>  account.
> 
>  Someone posting on the forum under a false name will generate lots of
>  drama,
>  but nothing critical. The same goes for bugzilla, or any ml.
>  Now, someone moderating a forum and wrecking havoc would be
>  more problematic. The same goes for svn/git/packages/translation/etc.
> 
>  Maybe it is simple to remove membership from all group, except those
>  seen as
>  unsensitive ? ( ie, everything except default users group ).
> 
>  We also need to see when do we remove such access. IE, if someone after
>  X months
>  decide to find interest into doing stuff that requires Y privileges,
>  what should happen ?
> 
>  - let him do it without asking ( keep Y privileges )
>  - need to ask to have his privileges back
>  - need to redo the whole system from start ?
> 
>  I guess that depending on X and Y, of course, and so we need to have
>  first a list
>  of Y.
> 
>  Let's try with that :
>  - commit to developper svn
>  - commit to packages svn
>  - submit packages
>  - commit to web svn
>  - modifiy ldap
>  - do sysadmin stuff ( log everywhere, touch to config )
>  - planet subscription
>  ( insert bugzilla stuff )
>  ( insert blog privs )
>  ( insert i18n stuff )
>  ( insert forums stuff )
>  ( isert missing stuff )
> 
>  I assume that we can all agree that a leader/deputy/board member
>  resiging will have
>  board/leader/deputy access removed.

[...]

perhaps the user can just opt-out in identity, which could result in:
 - removal of userPassword attribute, effectively disabling login
 - and setting a disabled flag in LDAP, which could be taking into account in 
each application.
 - removal of membership in groups is also an idea. but we'd have to find out 
if there is no "accountability from the past" issue.

this would have the benefit of rejoining at a later time AND the accountability 
from the past of stuff doesn't disappear.

eg: suppose appl X logs what user Y does, and does so with the LDAP reference.

if the ldap entry really is deleted, stuff might go wrong.

just an idea.