[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Bits from the release team: the plans for etch

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



Attachment: signature.asc
Description: Digital signature

Reply to: