Re: Bug#72738: Unnecessary changes to /etc/passwd
Joey, thanks for taking the time to do this!!
Thus spake Joey Hess on Sat, Sep 30, 2000 at 03:18:36AM CDT
>
> Here's my experiment:
>
> It looks like I need to make some changes to your system. Without those
> changes some packages might not work correctly. The list of changes are
> listed above. For more documentation on the Debian account policies
> please read /usr/share/doc/base-passwd/README.
>
> Should I update your system? [Y/n] y
I believe I remember seeing this, so it's probable that this is where it
happened. I remember thinking something like "Oh, a script or program is
smart enough to compensate for other changes that have been made so that
everything will work together" and said 'y'. Doing a major system upgrade
on a production system, even in the wee hours of the morning, doesn't give
one the luxury of being able to go read everything that relates to
everything that goes by. If there's possibility of damage as well, this
paragraph ought to be a good deal more cautionary out front.
In all likelihood, this is what happened. I may have missed the details.
> If you didn't see that, it wasn't base-passwd that did this. If you did see
> it, it should be in your log file, right?
Don't I wish! I went through the system logs and there was nothing, and
update-passwd doesn't mention anything about logging on its man page. As
best I can tell there was no way to back out any changes - no backup, no
diff, no log. As I said elsewhere, prudent Unix system administration
dictates that any changes made by a program or script to a vital system
config file such as /etc/passwd or /etc/group ought to provide a way to back
out of any changes, even if it's only an audit trail in a log file.
> It seems we still haven't figured
> out what package is responsible here, or you somehow missed this during
> your upgrade.
I would guess that Christian is right on this, and this is where it
happened. What other process in any package install might make the same
sort of change?
> > NO package or update script has any
> > business changing entries in /etc/passwd which do not relate to the
> > functionality of the OS or of installed packages, ESPECIALLY if such an
> > entry relates to a subsystem which isn't even supported or offered as
> > package by Debian.
>
> That's not entirely accurate. It really goes like this: User id's
> between 0 and 99 and by definition[1] globally allocated system uid's
> under the control of the Debian project. Furthermore, base-passwd is the
> only package that is allowed to fiddle with them[1].
This brings up a very interesting point. Please excuse me if I go in to
some detail here but I want to put some arms and legs on it, and maybe you
can tell me how the Debian people come down on it.
One of the basic design concepts and traditions of Unix (and for this
purpose Linux is Unix) is that one should be able to take source and compile
it on any flavor of Unix (or as many as possible), on any one of a variety
of Unices and hardware platforms. Debian has a solid and well-oiled set of
GNU sdk tools for this. Everyone that's ever admin'ed a Linux system has
had to compile and install stuff this way. Open source development grew out
of this and depends on it. Such software may or may not adhere to Debian
policy or the Debian FHS, but any Linux distribution which isn't flexible
enough to accommodate this is out of the running. Likewise, software
configure/make routines need to be smart enough to figure out what works and
what doesn't, as most are.
On the other hand, Debian has a tightly integrated package management system
and pre-compiled packages designed for installation on Debian must adhere
strongly to Debian standards, the FHS, the package format, etc. Debian
policy is strict for good functional reasons. There are lots of .deb files
which comply, as they must.
So we have two parallel tracks for install and maintenance, both of which
ought to be supported in Debian and any other decent Linux distribution, but
which are potentially in conflict in some areas. I'm sure stuff along this
line has been discussed a lot within the Debian developers community, and
the balancing act required is very real. One of my good friends and
colleagues here is a solid Debian fan but is also a self-described "Unix
bigot" and won't install anything from deb packages beyond the base system.
The particular property in conflict here is the UID space from 0 though 99.
Frisch's 'Essential System Administration' says "Conventionally, UIDs less
than 100 are used for system accounts" which is also what I was taught
during my apprenticeship, and the Debian project has very pragmatic reasons
to lay claim to this UID space. On the other hand, at least a portion of
this number space ought to be available for "system accounts" installed by
conventional Unix methods. Majordomo needs a UID. Qmail needs 7 of them.
I'm sure Sam Varshavchik's courier MTA needs at least this many. There are
others - good, useful packages that work beautifully under Debian and for
one reason or another aren't yet or may never be turned into Debian
packages. If the entire range of system UIDs is reserved by the Debian
Project then what's left? 99% of the time it's a no-nevermind, and
functionally most such subsystems don't care what UID space they operate in,
but there are some that do care, and discriminate, such as Debian's
update-passwd. Same arguments apply to GID space.
So what's appropriate here? Do we say 0 -> 99 belongs to Debian, 100 -> 199
belongs to non-Debian system accounts, and the rest is user UID space, or
should the 0 -> 99 space be divided along this line, or what? Has this been
given any thought, or addressed by policy?
> This is complicated by the fact that majordom was distributed along with
> Debian in non-free until it was yanked during the freeze of potato[2].
Security and license problems combined! The use of majordomo with qmail
(not an entirely trivial integration) fixes some of the security problems, I
believe.
> Exactly how base-passwd should be updated to deal with that I don't
> know. User id 30 is still under Debian control, but probably shouldn't
> be added to the passwd file on new Debian installs (if the admin of such
> an install wants to install majordomo, they would have to use a uid in
> the range reserved for local users. We probably want to keep it around on
> upgrades to prevent breaking systems that still use majordomo.
This is logical. If the UID is 'reserved' but not used or overwritten then
we're safe in this regard. In the long run, however, some further
convention on UID allocation seems appropriate - a range completely under
the administration of the Debian Project, a range for non-Debian system
UIDs, and the rest local user UID space. I don't know, but from my position
out here in the trenches it looks like an issue that needs some thought, or
maybe has been given some thought and I'm just out of the loop.
> It makes
> little sense though to update it as base-passwd does now, since if it is
> modified it's probably because the admin has moved over to a local
> install now that majordomo is not supported by Debian.
I can submit this as a bug report, but I hope I've brought the issue
sufficiently to enough people's attention that y'all can carry the ball on
it.
> In any event, it probably wasn't deemed necessary to deal with this when
> majordomo was removed in the middle of the freeze, if anyone even
> thought about it.
Well these things DO have a way of cropping back up! Perhaps it can be
addressed in woody.
Joey, thanks very much for your thoughtful answer and for the time and work
you put into researching the problem and the issue! I've tried to ask some
intelligent questions here, and to make some constructive suggestions, and
if you or someone could answer my questions in the same spirit I'd once
again have a case of the warm fuzzies about the Debian technical
community :)
Ciao,
--
Lindsay Haisley | "Everything works | PGP public key
FMP Computer Services | if you let it" | available at
fmouse@fmp.com | (The Roadie) | <http://www.fmp.com/pubkeys>
http://www.fmp.com | |
Reply to: