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 [EMAIL PROTECTED] | (The Roadie) | <http://www.fmp.com/pubkeys> http://www.fmp.com | |
