Bug#295680: libc6: getgrname returns a result that doesn't belong to /etc/group
On 2005-06-19 15:06:20 +0200, GOMBAS Gabor wrote:
> On Sun, Jun 19, 2005 at 02:53:16AM +0200, Vincent Lefevre wrote:
> > Why doesn't Debian give the choice to the user when assigning a gid?
> > And why does it have hardcoded gids? i.e. why aren't gids allocated
> > at installation time?
>
> Most are allocated at package installation time nowadays but that won't
> help you if a group with the same name already exists in NIS.
This is annoying as this means that Debian machines won't integrate
correctly in foreign networks. Why don't these groups have a name
specific to Debian? For instance, I've noticed that exim4 creates
a Debian-exim group. So, why don't other packages follow the same
way, with a Debian-* group?
> The ones that are statically allocated have good reasons for that
> (well, except a couple of historic relics) as documented in the
> Debian policy.
The reason given by the Debian policy is:
Because some packages need to include files which are owned by these
users or groups, or need the ids compiled into binaries, these ids
must be used on any Debian system only for the purpose for which
they are allocated.
But the ids could be changed at package installation time, and it
should be possible to avoid ids hardcoded in binaries... Anyway,
since the the /etc/group file has the priority, I don't think this
is a problem (except the fact that such groups can get hidden) if
packages use local group names (Debian-*) to avoid clashes.
> > Why not? For instance, there could be a file on the system that
> > lists the gids not to be used for local groups.
>
> /etc/login.defs has some minimal support for this already. Also the
> Debian policy clearly lists the range for dynamic group creation. If
> your local NIS setup contradicts the Debian policy, that's bad luck
> for you.
Yes, there are several gids < 100. In particular, slocate has gid 21,
which is group fax under Debian.
> > But why doesn't Debian let me do that? For instance, I modified
> > some local gids to avoid clashes with NIS, but during a later
> > upgrade with apt, they were set back to their original values.
>
> You either did something wrong or you should file a bug against the
> base-passwd package. It should have asked on upgrade whether it
> should reset the GIDs to their original values or not.
Well, I was asked the question, but the dialog box said that if I
didn't answer positively, my Debian system would not work properly.
You see...
> > This wouldn't be a problem. I'm thinking of the "slocate" group,
> > that currently exists in the NIS database. And in fact it would be
> > much better to have such a group locally in a gid range that will
> > not be used by the NIS administrators. Since /etc/group has the
> > priority, this would work without any problem.
>
> - If you expect the slocate database to be stored on some shared file
> system (NFS) then you must use the GID defined in NIS and should never
> allocate a different GID locally
This is not the case. This is purely Debian's slocate system, and
the files are stored in /usr/bin and /var/cache, which are local.
> - If you want the slocate database to be stored on local storage then
> you should not have put the slocate group in NIS in the first place
But this isn't me that put the slocate group in NIS. I couldn't do
anything about that (I'm not the sysadmin).
--
Vincent Lefèvre <vincent@vinc17.org> - Web: <http://www.vinc17.org/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.org/blog/>
Work: CR INRIA - computer arithmetic / SPACES project at LORIA
Reply to: