Re: Bug#72738: Unnecessary changes to /etc/passwd
Lindsay Haisley wrote:
> I read with my eyes, not by hand :) Every time I was presented with a
> notice which required my attention and some sort of input or keypress to
> continue I read it thoroughly. If it indicated some action that needed to
> be taken, such as manual reconfiguration of stuff in /etc/pam.d to
> reproducte the functionality of /etc/suauth or a warning about possible
> problems, I took care of it immediately on another vt and where appropriate
> I copied the screen data to a review file.
Here's my experiment:
root@kite:/home/joey>grep majordom /etc/passwd
majordom:x:30:31:Majordomo:/var/qmail/majordomo:/bin/sh
root@kite:/home/joey>apt-get --reinstall install base-passwd
Reading Package Lists... Done
Building Dependency Tree... Done
0 packages upgraded, 0 newly installed, 1 reinstalled, 0 to remove and 2 not upgraded.
Need to get 0B/14.6kB of archives. After unpacking 0B will be used.
Do you want to continue? [Y/n]
(Reading database ... 95354 files and directories currently installed.)
Preparing to replace base-passwd 3.1.7 (using .../base/base-passwd_3.1.7.deb) ...
Unpacking replacement base-passwd ...
Setting up base-passwd (3.1.7) ...
Checking if your system passwd, shadow and group files are correct...
Changing homedirectory of majordom to /usr/lib/majordomo
Would commit 1 changes
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
Okay, I am going to make the necessary updates now
Reading passwd from /usr/share/base-passwd/passwd.master
Reading group from /usr/share/base-passwd/group.master
Reading passwd from /etc/passwd
Reading shadow from /etc/shadow
Reading group from /etc/group
Changing homedirectory of majordom to /usr/lib/majordomo
1 changes have been made, rewriting files
Writing passwd-file to /etc/passwd.upwd-write
Replacing "/etc/passwd" with "/etc/passwd.upwd-write"
Writing shadow-file to /etc/shadow.upwd-write
Replacing "/etc/shadow" with "/etc/shadow.upwd-write"
Writing group-file to /etc/group.upwd-write
Replacing "/etc/group" with "/etc/group.upwd-write"
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? It seems we still haven't figured
out what package is responsible here, or you somehow missed this during
your upgrade.
> 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 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].
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. 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.
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.
--
see shy jo
[1] See the Debian Packaging Manual, section 3.2.
[2] Due to a security hole its license did not allow us to distribute
fixes for.
Reply to: