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

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



On 2005-06-18 23:55:13 +0200, GOMBAS Gabor wrote:
> No. But if you want to use NIS you have to be familiar with the
> consequences. If your local NIS policy allows having groups with IDs <
> 1000 in NIS maps, then you should better be prepared that automatic group
> creation _will_ fail and you have to fix it up manually. There is nothing
> Debian can do about it.

Is this rule of not having NIS group IDs < 1000 standard?
If so, is it possible to request that the NIS client ignores
such groups? This would make sense.

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?

> > I don't have such information, but I could probably ask them. The
> > problem is that they don't support Debian, so that their group id
> > range will conflict with Debian's group id range (in particular
> > because some group ids are hardcoded in Debian).
> 
> Then you have no other option than to synchronize your local group IDs
> with NIS manually.
> 
> NIS enforces a central policy that is defined by the NIS administrators.
> The package management system has no way to know about that policy.

Why not? For instance, there could be a file on the system that lists
the gids not to be used for local groups.

> If you want to be part of a NIS setup you have to manually adapt the
> local system configuration to match the central policy.

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.

> > Moreover, if some group exists in the NIS database, why isn't it
> > possible to have a copy (with the same group id) in /etc/groups?
> > This could be useful when the NIS server is down, for instance.
> 
> It is possible but you have to do it manually. This cannot be
> automated in general (think about the group ID being changed in NIS
> but not in your local copy).

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.

More generally, it seems perfectly valid for a Debian package that
needs to create a group for local use only to really create the
group instead of reusing a NIS one.

-- 
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: