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

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



On Wed, 26 Oct 2005 11:11:00 +0200, Javier Fernández-Sanguino Peña
<jfs@computer.org> wrote:
>On Wed, Oct 26, 2005 at 08:18:42AM +0200, Marc Haber wrote:
>> Thus, in most cases, a single call to adduser is all that's needed to
>> create a system user in postinst.
> 
>I have yet to see a package that "just" calls adduser.

Well, exim4, console-log, rageircd and ippl do. These are the ones
that I know for sure without thinking too long.

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

>> Your code, otoh, will overwrite local configuration which is an RC
>> bug.
>
>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.

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.

>> > There's some code that needs to be written to cope
>> >with different packaging situations that adduser is unable to
>> >contemplate by itself.
>> 
>> Which situations?
>
>For example:
>
>- Creating the user's homedir and assigning proper permissions if (and only
>if) the admin has not overriden it with dpkg-statoverride

What are "proper permissions" other than user:usersgroup 755, as
configured for the entire systems?

>- Adding the user to additional groups if required

adduser user group

>> Removing system users on package purge is widely regarded a bug since
>> one cannot guarantee that the local admin hasn't used the account for
>> other things as well. Additionally, removing the system user on
>> package purge might leave orphaned files around. If the maintainer
>> decides to remove a user in postinst, that can be done with an
>> explicit deluser call.
>
>That really depends on the daemon itself don't you think?

No. You never know what the local admin uses an account for.

>> Frankly, I do not see any advantage in your dh_user idea.
>
>Quite frankly, I do.

Go ahead. Maybe it's still even useful. Just the fact that I ditched
the plans for writing something like that doesn't mean that it might
not be useful. I'd just prefer adduser to take that task without
external help because collaboration might be useful.

For example, having the possibility to add a new account to a list of
groups _in_ _adduser_ would close two wishlist bugs against adduser
and ease account creation for the installer. Having that feature
"added" externally doesn't help here and indeed decreases the chance
for these wishlist bugs to be addressed in any reasonable time frame.

Greetings
Marc

-- 
-------------------------------------- !! No courtesy copies, please !! -----
Marc Haber         |   " Questions are the         | Mailadresse im Header
Mannheim, Germany  |     Beginning of Wisdom "     | http://www.zugschlus.de/
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834



Reply to: