Package-created usernames
I think we probably have enough bandwidth (or will do shortly) to take
on another item from our todo list. #429671 on username policy seems
to me to be where we can most obviously improve the situation so I'm
going to start there.
The problem which Marc Haber (Exim maintainer) is trying to solve is
the possibility of username clashes between usernames chosen by
package maintainers for use by those packages, and usernames chosen
by users and administrators (both for human beings and for local use).
I agree with Marc that this is a problem which we ought at least to
try to solve. In particular, because:
1. It is not always easy to avoid being bitten by this problem.
Because there is no global (really global!) registry of reserved
usernames, it is quite possible for a site administrator and a
Debian package maintainer to allocate the same username without
either of them necessarily being at fault.
2. When a clash does occur the consequences can be very severe
for the affected site.
The only effective options available to the administrator are
(a) to change the username of the locally allocated user, which
is in many environments a very serious undertaking. It is
likely to be technically and politically awkward and cause
ongoing problems (because usernames are stored not just in
computers but also in the minds of people). I have personal
experience of changing usernames on my colo system and it's
quite hard work.
(b) to permanently maintain a fork of the Debian package(s) in
question (or perhaps if they're lucky just deal with
configuration file conflicts forever more). Often an actual
fork will be needed because many programs have usernames
compiled in.
(c) not to install the packages and to use something different (eg,
a different operating system).
(d) to persuade the Debian maintainer to change the name (which is
likely to be very difficult).
All of these are very unattractive.
3. The solution, to divide up the namespace, is fairly
straightforward. The only deficiencies of this approach are
(a) that some people might consider the names from the
new Debian-reserved namespace somewhat ugly
(b) the new names might be somewhat longer.
Some people may argue that the new names may break existing software
but this is known not to be the case. Debian's Exim packages have
been using long names with capital letters for some time now without
serious problems - the only glitch I'm aware of personally is that
the very long names involved aren't always displayed in the most ideal
manner.
I have been giving special-purpose accounts names starting with
specific capital letters (for example, I independently invented S* for
Slip accounts) on chiark for years and it works well.
It might be argued that it is too disruptive to change all the
packages' reserved names. However, that is a separate question: it
would be quite possible to grandfather some subset of the
already-allocated names and merely solve the problem for names
allocated in the future.
The only question remaining to be decided is what the form of the new
names ought to be.
I would lean towards choosing a representation which allows us to
continue to use short names for system accounts. DJB's proposal of an
initial capital letter has some merit, and it seems that the obvious
choice would be `D' for names allocated by Debian. The remainder of
the name should consist of no more than 7 lowercase alphanumerics.
An additional advantage to using a capital letter is that there are
already many programs which do not treat users with capital letters as
`real' users. For example, Exim itself in a usual configuration will
ignore passwd file entries which are not lowercase, because it
lowercases usernames before looking them up.
On the question of grandfathering, I would suggest that we explicitly
bless at least
- the commonly-known UNIX user and group names
(someone should go through base-files and check the list there)
- existing packages already using names with capital letters in
them
Ian.
Reply to: