This one time, at band camp, Marc Haber said:
> I'd like to see deluser --system having a configuration option which
> would prevent an account from actually being deleted. That way, a
> local administrator could make sure that UIDs are not being re-used.
> 
> If this option is enabled, deluser --system would set the shell to
> /bin/false and invalidate the password (I am not sure whether the
> password should be destroyed or invalidated in a reversible way).
> 
> The default would, of course, be current behavior with actually
> deleting the account.

This is repeating logic already available (chsh and passwd -l) that
don't really buy all that much security.  passwd -l doesn't prevent key
based logins, for instance.

I'd rather see the logic work another way:

Add a --permanent flag to adduser, which writes the uid to a state file.
Make deluser exit 0 (or some specific non-zero) if called for a uid in that 
file.
Add --force to deluser to override it.

Maintainers could then individually decide if they think the accounts
they set up are sensitive enough to be worth preserving, and call chsh
and passwd -l themselves in postrm, or, maybe better:

if deluser $user; then
  if [ $? = 6 ]; then
    chsh -s /bin/false $user
    passwd -l $user
  else
    ...
  fi
fi

This would mean making deluser return something non-zero, and
documenting how to use it for maintainer scripts.  This would allow the
local admin to easily override maintainer decisions about what uid's are
too important to remove.

I'm open to other suggestions, but that's how I see it.

Take care,
-- 
 -----------------------------------------------------------------
|   ,''`.                                            Stephen Gran |
|  : :' :                                        [EMAIL PROTECTED] |
|  `. `'                        Debian user, admin, and developer |
|    `-                                     http://www.debian.org |
 -----------------------------------------------------------------

Attachment: signature.asc
Description: Digital signature

Reply via email to