Your message dated Fri, 23 Aug 2013 22:48:22 +0200
with message-id <20130823204822.GA683@nicolas>
and subject line Re: Bug#582347: newgrp doesn't work with groups that exist
both in nss source and locally
has caused the Debian Bug report #582347,
regarding newgrp doesn't work with groups that exist both in nss source and
locally
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 this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)
--
582347: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=582347
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: login
Version: 1:4.1.1-6+lenny1
Severity: normal
the scenario is simple: i have libnss-ldap installed and accounts and groups
are "virtual" in that they are only listed in ldap.
nsswitch.conf lists "ldap" as the first source for passwd, group and shadow,
and "files" second.
that works all fine, id shows the correct group memberships etc - with the
exception of newgrp and sg.
if i have a group membership definition for, say, group cdrom
in ldap (with the gid properly matching the entry in /etc/group),
then "newgrp cdrom" asks for the (nonexistent) group password and
refuses access. this happens for all the members
of group cdrom (and id confirms that just fine).
the cause of the problem in detail: the main group retrieval in line 564 of
src/newgrp.c works fine, it retrieves the appropriate info from ldap via nss.
however, line 587 contains an unconditional call to getsgnam and
a subsequent replacement of the ldap-sourced group membership with
this (inappropriate) result of getsgnam if getspnam succeeds.
getsgnam isn't nss-aware and always only reads /etc/gshadow, so for
groups that exist in both ldap (autoritative and complete) and gshadow
(empty and only as an installation artefact) the real group membership
is thrown out.
newgrp then wrongly concludes that the group is empty, so you're not
a member of it and therefore let's ask for the (nonexistent) group password
and let's not let you in.
as far as i can tell the nss system doesn't seem to provide any mechanism
for nss-ifying gshadow, so i'm not sure what the cleanest solution
for this problem would be.
however, i've got at least a workaround to offer: removing /etc/gshadow
inhibits the incorrect code and both ldap-sourced as well as local-only
group memberships are detected correctly.
as far as i can tell there aren't any adverse effects of not having
a shadow group file if you don't use group passwords.
regards
az
-- System Information:
Debian Release: 5.0.4
APT prefers stable
APT policy: (990, 'stable'), (980, 'testing'), (970, 'unstable')
Architecture: i386 (i686)
Kernel: Linux 2.6.31.9 (SMP w/2 CPU cores)
Locale: LANG=C, LC_CTYPE=de_AT (charmap=ISO-8859-1)
Shell: /bin/sh linked to /bin/dash
Versions of packages login depends on:
ii libc6 2.7-18lenny2 GNU C Library: Shared libraries
ii libpam-modules 1.0.1-5+lenny1 Pluggable Authentication Modules f
ii libpam-runtime 1.0.1-5+lenny1 Runtime support for the PAM librar
ii libpam0g 1.0.1-5+lenny1 Pluggable Authentication Modules l
login recommends no packages.
login suggests no packages.
-- no debconf information
--- End Message ---
--- Begin Message ---
Hello,
If there is an entry in gshadow for the group, then newgrp is right to assume
that gshadow is enabled for this group.
The behavior is well defined in newgrp manpage. I don't what else could be in
newgrp.
When admins decide to use LDAP, they should be consistent and
* disable gshadow
* or maintain gshadow manually so that groups which need gshadow features can
be cherry picked
Best Regards,
--
Nekral
--- End Message ---
