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 --------------------------------------------------------- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]