Bug#295680: libc6: getgrname returns a result that doesn't belong to /etc/group
On 2005-06-28 19:37:56 +0300, Lars Wirzenius wrote: * getgrnam(3) is wrong to say that only /etc/group is used. I've filed a bug against it (#316102). OK, but this is #316117. -- Vincent Lefèvre [EMAIL PROTECTED] - 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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#295680: libc6: getgrname returns a result that doesn't belong to /etc/group
On Mon, Jun 20, 2005 at 12:40:45AM +0200, Vincent Lefevre wrote: 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? 1. Too long (ps, top, ls -l etc. will not be able to display the whole name) 2. When there is an upstream default for the group name I'd be most annoyed if Debian diverged from that 3. There are no solaris-*, aix-*, redhat-* etc. groups and still these systems can be integrated in the same NIS domain quite nicely (been there, done that). Of course, that needs some planning _before_ setting up the NIS domain... 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. Ok, let's see: - root, daemon, bin, sys, adm, mail, news, uucp, www-data, nogroup: do not belong to any single package so cannot be changed dynamically (just think of the implications if the mail group ID changed when you install a different MTA and you suddenly can't read your mail - b...) - tty, disk, kmem, lp, dialout, fax, voice, cdrom, floppy, tape, audio, video: used for device nodes, so cannot be dynamic - man, sudo, shadow, utmp, sasl, plugdev: either too basic or too special so it's not worth allocating them dynamically - backup, operator, list, irc, gnats, games, staff, users: these historically exist and some packages may have them hardcoded for historical reasons. Also they do not belong to any single package so they cannot be allocated dynamically - there are 3 more left in /usr/share/base-passwd/group.master that I do not care to look up Yes, there are several gids 100. In particular, slocate has gid 21, which is group fax under Debian. Then your NIS setup is _broken_ and Debian can do nothing about it. Complain to your local NIS administrators. 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... Then you got what you've asked for. 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). I repeat again: if you want to use NIS, _you_ have to play by the rules set by the NIS administrators. If the NIS setup is broken, _you_ will have to fix the mess manually. There is absolutely _nothing_ Debian can do about it so please stop complaining in the BTS. 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 - -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#295680: libc6: getgrname returns a result that doesn't belong to /etc/group
On 2005-06-20 13:16:27 +0200, GOMBAS Gabor wrote: On Mon, Jun 20, 2005 at 12:40:45AM +0200, Vincent Lefevre wrote: Yes, there are several gids 100. In particular, slocate has gid 21, which is group fax under Debian. Then your NIS setup is _broken_ and Debian can do nothing about it. Complain to your local NIS administrators. OK, you didn't say that there was such a standard rule. I've sent a mail to the admins. -- Vincent Lefèvre [EMAIL PROTECTED] - 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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#295680: libc6: getgrname returns a result that doesn't belong to /etc/group
On Mon, Jun 20, 2005 at 01:45:17PM +0200, Vincent Lefevre wrote: OK, you didn't say that there was such a standard rule. I've sent a mail to the admins. The rules are: 1. If you want to support a certain operating system/distribution then don't put any groups/users in NIS that conflict with the default setup of that operating system/distribution. 2. If you did not follow rule #1 then don't complain when something breaks. These rules are not standard but just plain common sense. 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 - -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#295680: libc6: getgrname returns a result that doesn't belong to /etc/group
On 2005-06-20 14:11:56 +0200, GOMBAS Gabor wrote: The rules are: 1. If you want to support a certain operating system/distribution then don't put any groups/users in NIS that conflict with the default setup of that operating system/distribution. This means that Debian (in particular) won't necessarily integrate nicely in a foreign network. There are at least 2 valid reasons that it may be difficult to follow this rule: * The sysadmins cannot support every OS and cannot know every possible conflict. * The NIS database may contain old groups (but still valid), and their names may have been given even before a package/software using these names existed. Well, this is not future-proof. 2. If you did not follow rule #1 then don't complain when something breaks. These rules are not standard but just plain common sense. This is a bit naive to think that everything will work OK with rules that are not clearly defined standards (OS-independent). -- Vincent Lefèvre [EMAIL PROTECTED] - 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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#295680: libc6: getgrname returns a result that doesn't belong to /etc/group
On Mon, Jun 20, 2005 at 02:54:38PM +0200, Vincent Lefevre wrote: This means that Debian (in particular) won't necessarily integrate nicely in a foreign network. That's true for Solaris, AIX, Mac OS X etc. as well. There are at least 2 valid reasons that it may be difficult to follow this rule: * The sysadmins cannot support every OS and cannot know every possible conflict. Yes they should. It's their job. NIS is about _central_ management, which includes the list of supported configurations. If your configuration is not on that list, then you're on your own, and cannot expect things to 'just work'. * The NIS database may contain old groups (but still valid), and their names may have been given even before a package/software using these names existed. Well, this is not future-proof. Well, then do not use NIS/NIS+/LDAP etc. The same issues exist with other operating systems, there is nothing Debian-specific here. Setting up NIS is not easy, especially in heterogenous environments. You need a lot of knowledge about all to-be-supported-in-the-future operating systems/distributions, and you need a central policy about how to resolve the inevitable conflicts. But I said that a couple of times already... This is a bit naive to think that everything will work OK with rules that are not clearly defined standards (OS-independent). There are _NO_ standards for setting up NIS. And there will never be one as other major UNIX vendors will not change their default setups just for this (remember, Linux is not everything). But even if there are no standards there are a lot of common knowledge and rules of thumb that a good sysadmin should know about (such as low group and user IDs are problematic so it's best to avoid them). 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 - -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#295680: libc6: getgrname returns a result that doesn't belong to /etc/group
On 2005-06-20 15:58:00 +0200, GOMBAS Gabor wrote: On Mon, Jun 20, 2005 at 02:54:38PM +0200, Vincent Lefevre wrote: This means that Debian (in particular) won't necessarily integrate nicely in a foreign network. That's true for Solaris, AIX, Mac OS X etc. as well. That's why I said in particular. I don't know how these systems set up gids, but a system vendor who would really want to avoid these problems (knowing the local NIS policy) would be able to do that. There are at least 2 valid reasons that it may be difficult to follow this rule: * The sysadmins cannot support every OS and cannot know every possible conflict. Yes they should. It's their job. NIS is about _central_ management, which includes the list of supported configurations. If your configuration is not on that list, then you're on your own, and cannot expect things to 'just work'. Here the users choose the OS they want, so no, the sysadmins cannot support every OS. -- Vincent Lefèvre [EMAIL PROTECTED] - 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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
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 Lefvre [EMAIL PROTECTED] - 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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#295680: libc6: getgrname returns a result that doesn't belong to /etc/group
On Fri, Jun 17, 2005 at 07:56:10PM +0200, Vincent Lefevre wrote: Lots of Debian packages create local groups (and in fact, this is the only problem I have with local groups). So, what do you suggest? Not using Debian because it is a security bug? 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. $ ./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. So, this is a bug in Debian. No, it's a bug in your local NIS policy if you allow group IDs 1000 being served by NIS and still expect automatic local system group creation to work. 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. If you want to be part of a NIS setup you have to manually adapt the local system configuration to match the central policy. Of course, if you do not have a well-defined and well-designed NIS policy but rather it was just an ad-hoc setup then you will have difficulties... 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). 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]
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 Lefvre [EMAIL PROTECTED] - 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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#295680: libc6: getgrname returns a result that doesn't belong to /etc/group
On 2005-06-17 02:03:08 +0300, Lars Wirzenius wrote: Thus, I think the Linux manual page saying that getgrnam uses /etc/group only is a bug. 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. 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) In the NIS database, group 42 is doctex, but locally, it is shadow. My /etc/nsswitch.conf contains in particular: group: compat nis IMHO, since /etc/group has the priority and group 42 exists here, then the group doctex shouldn't have been visible. 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. -- Vincent Lefvre [EMAIL PROTECTED] - 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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#295680: libc6: getgrname returns a result that doesn't belong to /etc/group
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]
Bug#295680: libc6: getgrname returns a result that doesn't belong to /etc/group
On 2005-06-17 18:36:17 +0200, GOMBAS Gabor wrote: 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. Lots of Debian packages create local groups (and in fact, this is the only problem I have with local groups). So, what do you suggest? Not using Debian because it is a security bug? $ ./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. So, this is a bug in Debian. 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. 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). 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. -- Vincent Lefvre [EMAIL PROTECTED] - 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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#295680: libc6: getgrname returns a result that doesn't belong to /etc/group
At Thu, 17 Feb 2005 13:37:25 +0100, Vincent Lefevre wrote: The getgrname(3) man page says: The getgrnam() function returns a pointer to a structure containing the group information from /etc/group for the entry that matches the group name name. But here, the getgrname function returns a result that doesn't belong to /etc/group, which seems to lead by side effects to a security hole (more details below). Does this manpage say correctly? i.e. Is getgrnam tightly coupled with /etc/group? It gives here, where slocate is group 21 in NIS: $ ./grname slocate 21 (slocate) $ grep slocate /etc/group zsh: exit 1 grep slocate /etc/group $ grep 21 /etc/group fax:x:21: As a consequence: # touch blah # chown root.slocate blah # ls -l blah -rw-r--r-- 1 root fax 0 2005-02-17 13:30:13 blah ^^^ This could also explain why groupadd (to add a group to /etc/group) fails if a group with the same name exists via NIS. I guess you specify in /etc/nsswitch.conf that nis is prior than files for group lookup. Regards, -- gotom -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#295680: libc6: getgrname returns a result that doesn't belong to /etc/group
On 2005-02-28 10:12:14 +0900, GOTO Masanori wrote: At Thu, 17 Feb 2005 13:37:25 +0100, Vincent Lefevre wrote: The getgrname(3) man page says: The getgrnam() function returns a pointer to a structure containing the group information from /etc/group for the entry that matches the group name name. But here, the getgrname function returns a result that doesn't belong to /etc/group, which seems to lead by side effects to a security hole (more details below). Does this manpage say correctly? i.e. Is getgrnam tightly coupled with /etc/group? What do you mean? It gives here, where slocate is group 21 in NIS: $ ./grname slocate 21 (slocate) $ grep slocate /etc/group zsh: exit 1 grep slocate /etc/group $ grep 21 /etc/group fax:x:21: As a consequence: # touch blah # chown root.slocate blah # ls -l blah -rw-r--r-- 1 root fax 0 2005-02-17 13:30:13 blah ^^^ This could also explain why groupadd (to add a group to /etc/group) fails if a group with the same name exists via NIS. I guess you specify in /etc/nsswitch.conf that nis is prior than files for group lookup. My /etc/nsswitch.conf contains: group: files nis -- Vincent Lefèvre [EMAIL PROTECTED] - 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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#295680: libc6: getgrname returns a result that doesn't belong to /etc/group
Package: libc6
Version: 2.3.2.ds1-20
Severity: important
The getgrname(3) man page says:
The getgrnam() function returns a pointer to a structure containing the
group information from /etc/group for the entry that matches the group
name name.
But here, the getgrname function returns a result that doesn't belong
to /etc/group, which seems to lead by side effects to a security hole
(more details below).
Consider the following program:
#include stdio.h
#include stdlib.h
#include grp.h
int main (int argc, char **argv)
{
struct group *grp;
if (argc != 2)
{
fprintf (stderr, Usage: grname group_name\n);
exit (1);
}
grp = getgrnam (argv[1]);
if (grp == NULL)
{
fprintf (stderr, grname: can't find group %s\n, argv[1]);
exit (2);
}
printf (%d (%s)\n, grp-gr_gid, grp-gr_name);
return 0;
}
It gives here, where slocate is group 21 in NIS:
$ ./grname slocate
21 (slocate)
$ grep slocate /etc/group
zsh: exit 1 grep slocate /etc/group
$ grep 21 /etc/group
fax:x:21:
As a consequence:
# touch blah
# chown root.slocate blah
# ls -l blah
-rw-r--r-- 1 root fax 0 2005-02-17 13:30:13 blah
^^^
This could also explain why groupadd (to add a group to /etc/group)
fails if a group with the same name exists via NIS.
-- System Information:
Debian Release: 3.1
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: i386 (i686)
Kernel: Linux 2.6.10
Locale: LANG=POSIX, LC_CTYPE=en_US.ISO8859-1 (charmap=ISO-8859-1)
Versions of packages libc6 depends on:
ii libdb1-compat 2.1.3-7The Berkeley database routines [gl
-- no debconf information
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
