Your message dated Mon, 5 Feb 2007 18:20:02 +0100 with message-id <20070205172002.GA24114@mad.intersec.eu> and subject line reopening 295680 has caused the attached Bug report to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what I am talking about this indicates a serious mail system misconfiguration somewhere. Please contact me immediately.) Debian bug tracking system administrator (administrator, Debian Bugs database)
--- Begin Message ---
- To: Debian Bug Tracking System <submit@bugs.debian.org>
- Subject: libc6: getgrname returns a result that doesn't belong to /etc/group
- From: Vincent Lefevre <vincent@vinc17.org>
- Date: Thu, 17 Feb 2005 13:37:25 +0100
- Message-id: <20050217123725.GA22298@dixsept.loria.fr>
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-7 The Berkeley database routines [gl -- no debconf information
--- End Message ---
--- Begin Message ---
- To: 295680-done@bugs.debian.org
- Subject: Re: reopening 295680
- From: Pierre HABOUZIT <madcoder@debian.org>
- Date: Mon, 5 Feb 2007 18:20:02 +0100
- Message-id: <20070205172002.GA24114@mad.intersec.eu>
- Mail-followup-to: 295680-done@bugs.debian.org
- In-reply-to: <20060713175427.3FD66280E5@wavehammer.waldi.eu.org>
- References: <20060713175427.3FD66280E5@wavehammer.waldi.eu.org>
On Thu, Jul 13, 2006 at 07:54:27PM +0200, Bastian Blank wrote: > # Automatically generated email from bts, devscripts version 2.9.20 > reopen 295680 except that the bug was already closed before that (TTBOMK). and IMHO there is nothing surprising in the problem that has been discussed here, ldap and other nss modules work the same way. As soon as you use a multiple nss database scheme, you're on your own to avoid problems. a good way is to avoid to put system user/groups on your third party NSS. else, puting 'compat' first in the /etc/nsswitch.conf is enough to make the local database override NIS/Ldap/... and since the man page has been corrected... I see absolutely no reason to keep that bug open. -- ·O· Pierre Habouzit ··O madcoder@debian.org OOO http://www.madism.orgAttachment: pgpgqynW6GtDu.pgp
Description: PGP signature
--- End Message ---