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

Re: [debian-devel] Policy on Account creation and deletion?



Hi!

A levelezőm azt hiszi, hogy Marc Haber a következőeket írta:
> 
> (1) Account Name
> This has been discussed in the past, with no real consensus being
> reached. It is clear that we should use a namespace that doesn't clash
> with names that our users my use on their systems since we might
> remove an account that the local administrator manually created.
> Possibilities include _foo, foo_, Debian-foo and foo-Debian, with the
> only package I am aware of that already does this being exim4 (using
> Debian-exim, and receiving gazillion of bug reports "this account name
> is ugly").

I guess that an account name which have small possibility to clash is
necessarily ugly. And also have higher potential that it is not
handled correctly by some utils not handling unusual cases correctly
(I remember that I did have problems with username www-data).

Keeping it in mind I would still stick to names with small possibility
of clash.

> (2) Creation
> Most packages create their account in postinst. exim4 uses getent to
> determin whether the account already exists (this has shown to be
> unreliable, see #237657), and bind9 touches a file in /var/run and
> tries to chown the file to the account name before creating the
> account (with a comment basically saying that there is no other way to
> detect account existence).

Which is basically the case.

> 
> I am wondering what a package should do if the account already exists:
>    * use this account verbatim?
>      This might be undesireable as the account might be in use for
>      something else.
>    * delete and recreate the account using the package's settings?
>      This might overwrite a change done by the local admin, and it
>       might break unrelated local subsystems using this account.
>    * fail
>      This is the safest method, but probably undesireable as well.

It might be made dependent on the uid, as we have an uid range allocated
for technical accounts.
I would choose between verbatim usage and failure. To use the account
verbatim, it should be checked to be the one created fo our purposes:
uid, gecos, etc.

> 
> (3) Deletion
> I think that the account should be deleted when the package is
> uninstalled. dpkg documentation says that the only difference between
> remove and purge is that remove doesn't delete conffiles while purge
> does. This can be interpreted as a requirement to remove the account
> even on remove, which might lead to files becoming unowned.

No. And the reason is manyfold. One is the work you mention which
should be done on remove, and not the amount of it (as it should be
done on disable in most cases also), but the possibility to forget
something (did you remove postgres user, which is created with
the same uid in postgres per default?). 

> So, it might be necessary to chown all files owned by the package
> account to root:root when removing, and to chown them back to the
> newly created package account on installation. This can create a
> significant amount of work in the maintainer scripts.
> 
> Other people say that an account should - once created - never be
> automatically removed to block the uid from being recycled because of
> file ownership purposes. While these people surely have a point, I
> think this is a violation since our users depend on leaving the system
> in its original state after purge.

I think that security have priority. And we are talking about the system
uid range which should not clash with user expectations in any way
anyway.

-- 
GNU GPL: csak tiszta forrásból



Reply to: