On Wed, Oct 26, 2005 at 12:16:43PM +0200, Marc Haber wrote:
> On Wed, 26 Oct 2005 11:11:00 +0200, Javier Fernández-Sanguino Peña
> <jfs@computer.org> wrote:
> >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.
Hmm.. I guess you refer to the usermod use, which could be moved into the 'if
getent passwd' clause. Aborting installation when the user already
exists is something that could be avoided.
> 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.
That's precisely why providing a "best practices" is needed. Currently there
are too many packages using their own implementation of the above, if there
is no consensus on how it should be implemented there can hardly be a policy
item for those.
> >- 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?
For security reasons, it might make sense for some daemon files/directories
to be 640 (750 for dirs) or, even 600 (700 for dirs). Some daemons handle
sensible information in their directories which should be not be available
for other users.
> >- Adding the user to additional groups if required
>
> adduser user group
Which needs to be done:
a) once the user has been created
b) once the group has been created
So it's three calls to adduser in that case:
- create the user
- create the group
- add the user to the group
> >That really depends on the daemon itself don't you think?
>
> No. You never know what the local admin uses an account for.
Packages should not try to cope with every possible thing an admin can do.
There should be flexibility to have the admin make an informed decission, but
there should be a sane default valid for most installations. That's why
removal might be an optional feature in a 'dh_user' implementation which
should be, even, handled by a debconf question. Again, more code that is the
same across packages and could be added into the maintainer scripts
automatically by dh_user.
> 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.
The fact is, those features are already "added" externally, in inconsistent
ways, and without a clear policy stating how it should be implemente. So
maintainers can close bugs related to their decissions freely even if they
don't agree with the "general consensus". So there is no difference if a
'dh_user' is written. With the added benefit that it would:
- make implementation uniforms and favor code reuse
- define a common practice that would later be able to turn into policy
IMHO of course.
Javier
Attachment:
signature.asc
Description: Digital signature