* Marc Haber (mh+debian-devel@zugschlus.de) wrote:
> On Wed, 26 Oct 2005 11:11:00 +0200, Javier Fernández-Sanguino Peña
> <jfs@computer.org> wrote:
> > Some remove the user
> >(and fail to check if it was created by the postinst/preinst and not by the
> >alocal admin),
>
> Removing the user is a general bug, IMO. They cannot guess what the
> local admin did with the account while the package was installed.
I disagree with the idea that removing a user is a bug. If the user was
added by the package, and the package is being purged, and there's a
reasonable expectation that it wasn't used outside of the package's use
of it then I think it's probably safe to remove it. sshd is a good
example of this, imv. I'm already unhappy about the clutter in my
passwd/shadow files, having packages never be allowed to remove users
(which they created originally, etc) would just make it that much worse
for me, as a user.
> >Please explain, the code only changes /etc/{passwd,shadow,group}. Where's the
> >RC bug?
>
> If I generate user foo and give it some attributes, and some packages
> comes and overwrites these attributes, it has overwritten local
> configguration, and I would be Not Amused. The only sensible thing
> that a package can do in this situation is abort installation.
I'm not entirely sure I agree that's the *only* sensible thing which
could be done. Could it be posed as a question to the admin, use the
attributes as specified, or change them? Depending on the capabilities
of the package, of course.
> Some packages have tried to minimize the collision probability by
> using a prefix such as "Debian-" for their account, but until Debian
> has established Policy about that it's only a token measure.
The whole "Debian-" bit is just dumb(tm). Of course, so is hard-coding
usernames into packages (it's even better when there's a config option
to specify the username!). Collisions need to be dealt with in some
sane way, just attempting to avoid them is foolishness. What if the
admin *does* create a "Debian-blah" system account? I don't think just
overriding what the admin did would be right in that case either,
'reserved' namespace or not.
Thanks,
Stephen
Attachment:
signature.asc
Description: Digital signature