[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Passwd/Group changes status v3.



On Thu, 21 Nov 1996 17:44:00 GMT Ian Jackson (ian@chiark.greenend.org.
uk) wrote:

> Philippe Troin:
> > Remains:
> >  o Majordomo problem:
> > Still waiting for someone to confirm that the following change is 
> > harmless. Otherwise, rex will roll out with the bug:
> >         /etc/passwd:
> >                 majordom:*:30:30:majordomo:/var/majordomo:/bin/sh
> >         /etc/group:
> >                 majordom:*:31:majordom
> > To become:
> >         /etc/passwd:
> >                 majordom:*:30:31:majordomo:/usr/lib/majordomo:/bin/sh
> >         /etc/group:
> >                 majordom:*:31:
> 
> I've looked at this, and it seems odd to me.  The majordomo package
> contains indeed files with uid 30 and gid 31, but this seems to me to
> be a mistake.
> 
> I'd be inclined to say that we should change the majordomo gid to 30
> and offer the user the option (if they have majordomo installed) of
> reallocating its files - either not at all, or by running find on
> /var/lib/majordomo, or by running find on all local filesystems.

GID 30 is already used by group `dip'. The correct UID and GID for 
majordom are 30 and 31. As there is no majordomo maintainer right 
now, I just want to fix the incorrect GID in the passwd file. Right 
now the UID majordom belongs to groups dip and majordom, obvisouly a 
problem.
Normally, the above thing shouldn't change anything.
But, better check.

> The majordomo package needs to be fixed.

No maintainer...

> >  o Qmail controversy:
> The best would be for adduser to have an option to test whether
> certain uids and names are allocated.  Qmail could first say
>  adduser --check-free --uid 65001 qmail<spong>
>  adduser --check-free --uid 65002 qmail<wibble>
>  ...
> and then
>  adduser --uid 65001 qmail<spong>
>  adduser --uid 65002 qmail<wibble>
>  ...
> 
> Use of set -e would prevent the package from installing if one of the
> uids or names was in use with another name or uid, and adduser could
> print a useful message.

Sounds good. These UIDs should be reserved whatsoever.
So if the adduser --check-free fails, we must print a message saying:
	You've got UID $UID allocated to user $USER, but it was reserved 
	for the Debian project. Please move this UID (and possibly all 
	other UIDs above 65000), and reconfigure this package.

> >  o Gnats doubt:
> > Brian C. White <bcwhite@verisim.com> wants to have its current UID for gnats to 
> > be changed so that it matches a newly allocated GID for gnats.
> > That raises the same problem that my previous proposal to roll out rex with stat
> > ic uids in the 0-99 range for Qmail and change them later on with bo.
> 
> Why don't we give gnats its existing UID as a GID instead ?

Gnats has got UID 21, and GID 21 is already allocated for fax.

Phil.


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
debian-devel-REQUEST@lists.debian.org . Trouble? e-mail to Bruce@Pixar.com


Reply to: