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

Bug#295680: marked as done (libc6: getgrname returns a result that doesn't belong to /etc/group)

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 --- 
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 --- 
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.org

Attachment: pgpgqynW6GtDu.pgp
Description: PGP signature


--- End Message ---
Reply to: