Bug#240836: libc6: Duplicated group-id's breaks NFS-access
At Mon, 29 Mar 2004 16:51:36 +0200 (CEST),
Anders Bostr�rote:
> I recently got problems accessing our NFS-server. Even if I was member
> of the right groups was my accesses denied by the server. After some
> investigation did I found out that the NFS-requests didn't contain all
> groups I am a member of. Also, most of the group-id's was duplicated
> in the NFS-requests.
>
> NFS has a limitation on the number of groups (16 I think) and as the
> groups are duplicated was that limit exceeded, and I was denied
> access.
Yes, NFS has limitation up to 16 groups with basic unix authentication.
> The normal system-utilities, like id gives this:
>
> >id
> uid=1006(anders) gid=100(users) grupper=4(adm),4(adm),7(lp),7(lp),14(sysadmin),20(dialout),24(cdrom),24(cdrom),25(floppy),25(floppy),25(floppy),29(audio),29(audio),40(src),40(src),44(video),44(video),50(staff),50(staff),100(users),101(telnetd),1006(anders),2000(cad),2002(install),2002(install),2017(cvsadmin),10001(linux)
> >
>
> For an example floppy is listed 3 times. A test-program using
> getgroups gives the same result, making it a libc6-problem.
>
> My /etc/nsswitch.conf looks like this:
>
> group: files nis compat
>
> and floppy exists in both files and NIS.
So this means that /etc/groups returned floppy entry, but even NIS
looking up is continuing. Strange. Please check where "floppy" group
is really come from.
BTW, does your /etc/passwd have a entry with starting "+" and
following ":"? If so, changing as follows:
group: compat
> I don't know if it is OK to return the same group-id several times
> from getgroups or not, BUT NFS (and system utilities like id) should
> not duplicate group id's.
The usual NFS implementation does not reject duplicated group ids
(AUTH_UNIX module only checks each group ids), and IIRC NFS
specification does not say anything about such ids.
> This problem is new, older versions of my system did not duplicate the
> groups-id's in NFS-requests. I update testing almost every day, and
> one month ago didn't the problem exist.
So I suspect your environment. Glibc 2.3.2.ds1 series did not touch
the original codebase these days.
Regards,
-- gotom
Reply to: