Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 25 May 2012 12:54:50 GMT
From:      Rune <u-fbmk4r@aetey.se>
To:        freebsd-gnats-submit@FreeBSD.org
Subject:   kern/168335: nfsv4 server with krb5 sec limits group number per uid to 16
Message-ID:  <201205251254.q4PCsoqh074299@red.freebsd.org>
Resent-Message-ID: <201205251300.q4PD09Qn054316@freefall.freebsd.org>

next in thread | raw e-mail | index | archive | help

>Number:         168335
>Category:       kern
>Synopsis:       nfsv4 server with krb5 sec limits group number per uid to 16
>Confidential:   no
>Severity:       serious
>Priority:       high
>Responsible:    freebsd-bugs
>State:          open
>Quarter:        
>Keywords:       
>Date-Required:
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Fri May 25 13:00:08 UTC 2012
>Closed-Date:
>Last-Modified:
>Originator:     Rune
>Release:        9.0
>Organization:
>Environment:
FreeBSD [hostname] 9.0-RELEASE FreeBSD 9.0-RELEASE #0: Tue Jan  3 07:46:30 UTC 2012     root@farrell.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC  amd64
>Description:
While accessing nfs shares exported with NFSv4 sec=krb5i,
no other export types,
vfs.nfsd.server_max_nfsvers: 4
vfs.nfsd.server_min_nfsvers: 4

access rights to be provided by some groups are not granted (permission denied).
A test reveals it to be the case with the groups not within the first 16 ones in the output of "id [-G] <account>" command (on the server).

A quick glance at the source suggests that it may have to do with

fs/nfs/rpcv2.h:#define    RPCAUTH_UNIXGIDS 16

which is being used in

./../rpc/rpcsec_gss/svc_rpcsec_gss.c:  gid_t cl_gid_storage[RPCAUTH_UNIXGIDS];
./../rpc/rpcsec_gss/svc_rpcsec_gss.c:  numgroups = RPCAUTH_UNIXGIDS;

This problem is a showstopper for a deployment (migrating from a *Solaris server) as we are using groups very extensively.

Regards,
Rune
>How-To-Repeat:
put an account in more than 16 unix groups
export a share over NFSv4 sec=krb5i  (well, any krb*)
create a directory not owned by the account, chgrp to the account's group with a highest gid (or otherwise "one of the later groups on its list"), chmod 770

access the share (e.g. from a RHEL5.6 Linux client) with the Kerberos credentials of the corresponding account

ls -ld <the-directory>   shows owner,group and the rwxrwx--- permissions
ls -l <the-directory>    yields "permission denied"

Note that the same test passes (no "permission denied") against both Solaris and Linux NFSv4 servers with the same Kerberos realm, passwd/group database, accounts and client hosts.
>Fix:


>Release-Note:
>Audit-Trail:
>Unformatted:



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201205251254.q4PCsoqh074299>