Bug#295680: libc6: getgrname returns a result that doesn't belong to /etc/group
On Sun, Jun 19, 2005 at 02:53:16AM +0200, Vincent Lefevre wrote:
> Is this rule of not having NIS group IDs < 1000 standard?
No. It's just a good rule of thumb for most cases.
> If so, is it possible to request that the NIS client ignores
> such groups? This would make sense.
No. There are very valid reasons for such groups coming from NIS. You
just have to be aware of the consequences.
> 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. The ones
that are statically allocated have good reasons for that (well, except a
couple of historic relics) as documented in the Debian policy.
> 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.
> 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.
> 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
- 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
- If you want to mix the above scenarios then you should have renamed
the group in NIS (and have patched slocate accordingly)
I can but only repeat myself: you should plan such things well _before_
setting up NIS. If you did not do so then you _will_ have a lot of
manual work cleaning up the mess.
Gabor
--
---------------------------------------------------------
MTA SZTAKI Computer and Automation Research Institute
Hungarian Academy of Sciences,
Laboratory of Parallel and Distributed Systems
Address : H-1132 Budapest Victor Hugo u. 18-22. Hungary
Phone/Fax : +36 1 329-78-64 (secretary)
W3 : http://www.lpds.sztaki.hu
---------------------------------------------------------
Reply to: