From owner-freebsd-bugs@FreeBSD.ORG Fri May 25 13:00:27 2012 Return-Path: Delivered-To: freebsd-bugs@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6DA601065674 for ; Fri, 25 May 2012 13:00:27 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 46D518FC19 for ; Fri, 25 May 2012 13:00:27 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q4PD09Lj054317 for ; Fri, 25 May 2012 13:00:09 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q4PD09Qn054316; Fri, 25 May 2012 13:00:09 GMT (envelope-from gnats) Resent-Date: Fri, 25 May 2012 13:00:09 GMT Resent-Message-Id: <201205251300.q4PD09Qn054316@freefall.freebsd.org> Resent-From: FreeBSD-gnats-submit@FreeBSD.org (GNATS Filer) Resent-To: freebsd-bugs@FreeBSD.org Resent-Reply-To: FreeBSD-gnats-submit@FreeBSD.org, Rune Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 681A7106566C for ; Fri, 25 May 2012 12:54:51 +0000 (UTC) (envelope-from nobody@FreeBSD.org) Received: from red.freebsd.org (red.freebsd.org [IPv6:2001:4f8:fff6::22]) by mx1.freebsd.org (Postfix) with ESMTP id 52A808FC0C for ; Fri, 25 May 2012 12:54:51 +0000 (UTC) Received: from red.freebsd.org (localhost [127.0.0.1]) by red.freebsd.org (8.14.4/8.14.4) with ESMTP id q4PCsonK074300 for ; Fri, 25 May 2012 12:54:50 GMT (envelope-from nobody@red.freebsd.org) Received: (from nobody@localhost) by red.freebsd.org (8.14.4/8.14.4/Submit) id q4PCsoqh074299; Fri, 25 May 2012 12:54:50 GMT (envelope-from nobody) Message-Id: <201205251254.q4PCsoqh074299@red.freebsd.org> Date: Fri, 25 May 2012 12:54:50 GMT From: Rune To: freebsd-gnats-submit@FreeBSD.org X-Send-Pr-Version: www-3.1 Cc: Subject: kern/168335: nfsv4 server with krb5 sec limits group number per uid to 16 X-BeenThere: freebsd-bugs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Bug reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 May 2012 13:00:27 -0000 >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] " 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 shows owner,group and the rwxrwx--- permissions ls -l 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: