Debian Bug report logs - #11979
base-passwd: wrong groups for majordom and postgres

Toggle useless messages

Message #5 received at submit@bugs.debian.org (full text, mbox, reply):

From: <nils@nus.de>

To: submit@bugs.debian.org

Subject: base-passwd: base-passwd: wrong groups for majordom and postgres

Date: Fri, 8 Aug 1997 17:54:11 +0200

Package: base-passwd
Version: 1.3.1

This is an extract from passwd in base-passwd:
proxy:*:13:13:proxy:/bin:/bin/sh
majordom:*:30:31:majordom:/usr/lib/majordomo:/bin/sh
postgres:*:31:32:postgres:/var/postgres:/bin/sh
www-data:*:33:33:www-data:/var/www:/bin/sh

This is an extract from group in base-passwd:
proxy:*:13:
kmem:*:15:
dialout:*:20:
fax:*:21:
voice:*:22:
cdrom:*:24:
floppy:*:25:
tape:*:26:
sudo:*:27:
audio:*:29:
dip:*:30:
majordom:*:31:majordom
postgres:*:32:
www-data:*:33:

Clearly majordom should be 31:31 and postgres should be 32:32
in passwd

This bug had beed fixed in 1.3.0 but apparantly slipped in in 1.3.1 again...


-- System Information
Debian Release: 1.2
Kernel Version: Linux dino 2.0.31 #1 Tue Aug 5 16:08:04 MET DST 1997 i586 unknown

Message #10 received at 11979@bugs.debian.org (full text, mbox, reply):

From: Galen Hazelwood <galenh@micron.net>

To: nils@nus.de, 11979@bugs.debian.org

Subject: Re: Bug#11979: base-passwd: base-passwd: wrong groups for majordom and postgres

Date: Mon, 18 Aug 1997 14:34:30 -0600

nils@nus.de wrote:

> Clearly majordom should be 31:31 and postgres should be 32:32
> in passwd

Yes, it should.  And it will never be, for two obvious reasons:

1) The current setup works.  The majordom passwd entry (30) points to
the correct group entry (31), even though they aren't the same.

2) If I change the assignment of names to numbers, every system which
has majordomo and postgres installed will break.  Remember that the file
system stores owners and groups as numbers, not symbols.  When majordomo
becomes 31 instead of 30, all the files which used to be owned by
majordomo are now owned by the non-existant user 30, and aren't
accessible by programs running under majordomo's permissions.  This is
Bad(TM).

Changing base-passwd in this particular way is a major no-no.  I don't
like the way things are set up now, but one of my predecessors did this,
and there's nothing I can do about it.

>
>
> This bug had beed fixed in 1.3.0 but apparantly slipped in in 1.3.1
> again...

No, this was a related (but different) problem, where the GID entry in
the passwd file's majordom line pointed to the wrong place.

I'm closing this bug.

--Galen

Message #15 received at 11979-done@bugs.debian.org (full text, mbox, reply):

From: Galen Hazelwood <galenh@micron.net>

To: 11979-done@bugs.debian.org

Subject: Not a fixable problem

Date: Mon, 18 Aug 1997 14:35:55 -0600

There's nothing I can do to change this, and no reason to mess with
something that works.

Message #20 received at 11979@bugs.debian.org (full text, mbox, reply):

From: joey@finlandia.infodrom.north.de (Martin Schulze)

To: galenh@micron.net (Galen Hazelwood), 11979@bugs.debian.org

Cc: nils@nus.de, 11979@bugs.debian.org

Subject: Re: Bug#11979: base-passwd: base-passwd: wrong groups for majordom and postgres

Date: Tue, 19 Aug 1997 00:49:06 +0200

Galen Hazelwood writes:

> > Clearly majordom should be 31:31 and postgres should be 32:32
> > in passwd
> 
> Yes, it should.  And it will never be, for two obvious reasons:
> 
> 1) The current setup works.  The majordom passwd entry (30) points to
> the correct group entry (31), even though they aren't the same.
> 
> 2) If I change the assignment of names to numbers, every system which
> has majordomo and postgres installed will break.  Remember that the file

Please exchange with those maintainers that they can improve their
postinst scripts.  It also would be nice if you could check in your
postinst script for those packages.

NB: nobody will update /etc/passwd from any .deb on a running system

> system stores owners and groups as numbers, not symbols.  When majordomo
> becomes 31 instead of 30, all the files which used to be owned by
> majordomo are now owned by the non-existant user 30, and aren't
> accessible by programs running under majordomo's permissions.  This is
> Bad(TM).

There are ways to get around this.  The msql.msql user normally has id
36 (or 37, don't quite remember), but sometime that user is already in
use on a running system, so my postinst scripts have to take care of
this nd chown -R the appropriate files.

> Changing base-passwd in this particular way is a major no-no.  I don't
> like the way things are set up now, but one of my predecessors did this,
> and there's nothing I can do about it.

I don't believe this.  There's always a way if one wants to go.

So: majordom could change the gid while a new base-passwd would
introduce the correct gif.  At least I would do so..

Regards

	Joey

-- 
  / Martin Schulze  *  joey@infodrom.north.de  *  26129 Oldenburg /
 /                 Beware of bugs in the above code; I have only /
/          proved it correct, not tried it.  -- Donald E. Knuth /

Message #25 received at 11979@bugs.debian.org (full text, mbox, reply):

From: Galen Hazelwood <galenh@micron.net>

To: Martin Schulze <joey@finlandia.Infodrom.North.DE>, 11979@bugs.debian.org

Subject: Re: Bug#11979: base-passwd: base-passwd: wrong groups for majordom and postgres

Date: Tue, 19 Aug 1997 10:29:52 -0600

Martin Schulze wrote:

>
>
> Please exchange with those maintainers that they can improve their
> postinst scripts.  It also would be nice if you could check in your
> postinst script for those packages.

I think it's unfair to ask maintainers to set their postinst scripts for
a situation which should never happen.  I feel that there is "unwritten
policy" which guarantees base-passwd entries are permanant except in the
most extreme emergencies.

>
>
> NB: nobody will update /etc/passwd from any .deb on a running system

Never, ever underestimate human stupidity.  :)


>
>
> > system stores owners and groups as numbers, not symbols.  When
> majordomo
> > becomes 31 instead of 30, all the files which used to be owned by
> > majordomo are now owned by the non-existant user 30, and aren't
> > accessible by programs running under majordomo's permissions.  This
> is
> > Bad(TM).
>
> There are ways to get around this.  The msql.msql user normally has id
>
> 36 (or 37, don't quite remember), but sometime that user is already in
>
> use on a running system, so my postinst scripts have to take care of
> this nd chown -R the appropriate files.

Sure, I could ask every maintainer to do massive chowns in case
base-passwd's "root" and "bin" entries had changed, but I don't, because
I guarantee stability.  In your case it makes sense, and I might mave a
word with the majordomo and postgres maintainers, but this seems to be
going to a lot of effort to fix what is really a trivial cosmetic
problem.

> > Changing base-passwd in this particular way is a major no-no.  I
> don't
> > like the way things are set up now, but one of my predecessors did
> this,
> > and there's nothing I can do about it.
>
> I don't believe this.  There's always a way if one wants to go.
>
> So: majordom could change the gid while a new base-passwd would
> introduce the correct gif.  At least I would do so..
>

And then we have to guarantee that the new base-passwd and majordom
packages are installed in the right order and at the same time.  What's
worse, we have to guarantee, not only the user installed the new
base-passwd, but that he manually folded the changes into the system
file.  Making /etc/passwd and group configuration files was a
mind-bogglingly stupid idea, and as soon as I get some time away from my
massive backlog of bug reports, I'm going to start work on the new
super-duper automatic passwd/group updater.  It looks like I'm going to
have to write it in C, making base-passwd an arch-specific package :( :(
:(, but that's the way it goes.

I'll reopen this bug and leave it open.  Once I have such a tool, I'll
act on this.  I might not even have to bother the other maintainers, if
I'm really clever.

--Galen

Message #32 received at 11979@bugs.debian.org (full text, mbox, reply):

From: joey@finlandia.infodrom.north.de (Martin Schulze)

To: galenh@micron.net (Galen Hazelwood)

Cc: 11979@bugs.debian.org

Subject: Re: Bug#11979: base-passwd: base-passwd: wrong groups for majordom and postgres

Date: Tue, 19 Aug 1997 19:07:38 +0200

Galen Hazelwood writes:

> > Please exchange with those maintainers that they can improve their
> > postinst scripts.  It also would be nice if you could check in your
> > postinst script for those packages.
> 
> I think it's unfair to ask maintainers to set their postinst scripts for
> a situation which should never happen.  I feel that there is "unwritten
> policy" which guarantees base-passwd entries are permanant except in the
> most extreme emergencies.

There's nothing unfair on it.  One reason for postinst scripts is to
rub out old bugs.  (take a look at the one from sysklogd or msqld,
both try to remove old bugs).

Nevertheless it's your decision, you're the maintainer.  I can only tell
you what I would do in such a situation.

> > NB: nobody will update /etc/passwd from any .deb on a running system
> 
> Never, ever underestimate human stupidity.  :)

Ok... shit... persuaded...
:)

> > > system stores owners and groups as numbers, not symbols.  When majordomo
> > > becomes 31 instead of 30, all the files which used to be owned by
> > > majordomo are now owned by the non-existant user 30, and aren't
> > > accessible by programs running under majordomo's permissions.  This is
> > > Bad(TM).
> >
> > There are ways to get around this.  The msql.msql user normally has id
> >
> > use on a running system, so my postinst scripts have to take care of
> > this nd chown -R the appropriate files.
> 
> Sure, I could ask every maintainer to do massive chowns in case
> base-passwd's "root" and "bin" entries had changed, but I don't, because

Don't start kidding.  I think you've gotton my point.

> I guarantee stability.  In your case it makes sense, and I might mave a
> word with the majordomo and postgres maintainers, but this seems to be
> going to a lot of effort to fix what is really a trivial cosmetic
> problem.

For my feeling it's extremely confusing having a pair of uid/gid but
not having the same numbers.

> And then we have to guarantee that the new base-passwd and majordom
> packages are installed in the right order and at the same time.  What's
> worse, we have to guarantee, not only the user installed the new
> base-passwd, but that he manually folded the changes into the system

Ask the user if he wants to perform the change and inform him that he
might run into trouble otherwise.  But again, if you don't like the
idea, skip it.  It's your decision.

> I'll reopen this bug and leave it open.  Once I have such a tool, I'll
> act on this.  I might not even have to bother the other maintainers, if
> I'm really clever.

*smile*

Regards

	Joey

-- 
  / Martin Schulze  *  joey@infodrom.north.de  *  26129 Oldenburg /
 /                 Beware of bugs in the above code; I have only /
/          proved it correct, not tried it.  -- Donald E. Knuth /

Message #43 received at 11979-done@bugs.debian.org (full text, mbox, reply):

From: Colin Watson <cjwatson@debian.org>

To: 11979-done@bugs.debian.org

Cc: Martin Schulze <joey@finlandia.infodrom.north.de>

Subject: Re: Bug#11979: base-passwd: wrong groups for majordom and postgres

Date: Sat, 8 Feb 2003 11:22:34 +0000

On Tue, Aug 19, 1997 at 12:49:06AM +0200, Martin Schulze wrote:
> Galen Hazelwood writes:
> > Changing base-passwd in this particular way is a major no-no.  I don't
> > like the way things are set up now, but one of my predecessors did this,
> > and there's nothing I can do about it.
> 
> I don't believe this.  There's always a way if one wants to go.
> 
> So: majordom could change the gid while a new base-passwd would
> introduce the correct gif.  At least I would do so..

What's actually happened over time is that the majordom ids were removed
in base-passwd 3.2.2 while the postgres ids were removed in 3.5.0. On a
fresh Debian installation or after those ids are manually removed from
the system database files, a modern version of postgresql will create
ids for itself in the system range, and any repackaging of majordomo
should do the same. I think that renders this bug report basically moot;
if a renumbering of ids needs to happen on systems with majordomo or
postgresql installed, it will be to outside the static range and is
therefore the responsibility of the postgresql and hypothetical
majordomo packages.

(Prompting users to remove obsolete ids from the system database files
is on the wishlist as #55890.)

Regards,

-- 
Colin Watson                                  [cjwatson@flatline.org.uk]

Send a report that this bug log contains spam.