Bug#295680: libc6: getgrname returns a result that doesn't belong to /etc/group

[GOMBAS Gabor <gombasg@sztaki.hu>]

On Fri, Jun 17, 2005 at 08:51:53AM +0200, Vincent Lefevre wrote:

> So, that would also make programs that rely on /etc/group being used
> buggy. IIRC, when I want to add a local group with addgroup, it checks
> first if it exists with getgrnam, and refuses to create it if it can
> be found. And this is an error if the group exists on NIS, but not
> locally in /etc/groups.

Huh? I was administering a large NIS setup a couple of years ago and
this _is_ the only acceptable behaviour. I'd consider blindly creating a
local group if it already exists in NIS a serious security bug as it may
silently break local group-based authentication schemes.

> Also, I wonder if the following is the correct behavior (grname is a
> program that calls getgrgid or getgrnam depending on the argument):
> 
> $ ./grname doctex
> 42 (doctex)
> $ ./grname 42
> 42 (shadow)
 
Yes, it is correct as far as libc is concerned. It is simply a
system administration error.

> IMHO, since /etc/group has the priority and group 42 exists here, then
> the group "doctex" shouldn't have been visible.

You make multiple incorrect assumptions here. First you think that the
id->name and name->id lookups are somehow connected but they are
completely independent. Second nothing stops you having several group
names resolving to the same group ID even in the same backend database.
It is allowed and it has some uses but it is not very common.

> Note that AFAIK, these mismatches are not avoidable when one wants to
> use a Debian machine in a NIS network and when the administrators of
> the machine and the network are not the same.

NIS is meant for _central_ administration. If you allow hosts on the
network that you have no control over then _you_ will have to keep both
pieces when something breaks.

When I was a NIS admin we had a document clearly defining the range of
user and group IDs allowed to exist both in NIS and on the local
machines (and it did include synchronizing even some system user and
group IDs like "mail" over several operating systems). You simply cannot
manage NIS without well-defined administrative rules.

Gabor

-- 
     ---------------------------------------------------------
     MTA SZTAKI Computer and Automation Research Institute
                Hungarian Academy of Sciences
     ---------------------------------------------------------