Base-passwd issues
Okay, it's obvious that my new base-passwd release has gone over like a
lead balloon. Oddly enough, nobody complained when I floated my ideas
on debian-devel a long time ago, and when I released it to experimental,
all I got was complements (and a few reasonably easy bug reports). Then
I put it in unstable, and WHAM!
I don't believe any package should have a prompt in post-install,
especially not critical base packages which might be upgraded without a
user present (I do that a lot). Therefore, I have two choices: I can do
as I'm doing now, or I can omit the call altogether and just print a
message telling the user to run update-passwd. I worry about the
latter, because many people will probably just forget to run it, or
might ignore the message. On the other hand, it's no worse than what we
had before, so that's the way I'll go.
Giuliano P Procida wrote:
> 1. The stupidity is in the lack of prompting. Renaming, numbering or
> deleting users and groups must be done with the sysadmin's consent.
> Prompting for cornfirmation should be onby default.
The uids between 0 and 99 are sacred, and allocated globally on all
Debian systems. Since no program can tell the difference between your
changes and obsolete stuff which needs changing, I'll add prompting to
update-passwd, but that (in my mind) destroys the whole point of the
package: perfectly transparent and automatic upgrades. Any newbies who
actually run update-passwd will get scared by the prompting and start
saying "no", and their passwd and group files will never get upgraded.
:(
> 2. What about shadow and gshadow? Modifications to those files should
> happen at the same time. Don't change "*" into "x".
I'll run the appropriate utilities at the end of update-passwd. I
forgot about this one.
> 3. Why no ftp or dos groups? What group would you put in their place?
I asked people about adding an ftp group to the master passwd file, but
was told that the mere _existance_ of an ftp user (on an system which
doesn't want to do anonymous ftp) constitutes a security hole. Is this
true? If not, I'll go ahead and put it in as UID 11.
No packages actually ever used dos. I suppose it was originally there
for dosemu, but it never actually used it. Nobody complained when I
suggested removing it. What were you using it for, and why can't you
use something else?
> 4. If you are going to renumber items the there should be an
> associated utility to find all the effected files, present them to
> the admin for immediate or later action. Any processes running with
> those uid or gids should also be presented to the admin.
I wrote in the todo list that this problem is "harder than you think"; I
stand by that assessment.
> 9. I just noticed, the program seems to "think" in terms of renaming
> uids but not in terms of renumbering users. It needs to do both to
> be useful.
I was originally going to do both, but found the latter to be extremely
difficult.
Anyway, I now have a better idea of what people actually want from an
automagic base-passwd (as opposed to what they told me they wanted when
I started this). I'll build 2.0.4 tonight, which will be 2.0.3 without
the postinst, which should stop upgrade problems. My next major set of
changes (2.0.5) will be the following:
-- Rewrite update-passwd in perl. I never wanted to do it in C to
begin with, but when I wrote it (early last fall) I knew little perl,
and didn't think I could emulate lckpwdf(3) using only perl-base. I
know a great deal more perl now, and think it might be possible. Many
of these hard problems mentioned above become much easier in perl.
-- Handle problems with NIS users and shadow password files. I don't
use either, so I never found these problems.
-- Update-passwd will now perform the sanity check by default, and
prompt for all changes by default. Warnings will be more verbose.
Files whose owner's UID has changed will be appropriately chowned.
Sorry I caused such a stir, folks. Hopefully I can get this working
quickly again.
--Galen
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: