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.
Hello, The bug is a showstopper, is there anybody looking at it?? Regards, Rune
Looking forward to a fix. We will be forced to drop FreeBSD as a server platform if there will be no near fix. Pity, it does not help that the OS is "mostly very good" - a small but crucial deficiency makes the whole worthless. Regards, Rune
Note that the lack of protection for the submitters addresses forces us to regularly disable/replace the addresses due to excessive spam. That's the reason why the original submitter mail address is no longer valid since today. This does not change the fact that we are interested in a fix and in the feedback. We are monitoring the issue web page. Note that we always post and repost from working addresses and that several months without a reply is a too long time to expect a single mail address to remain valid, given that _you_ publish it at once. The issue remains valid and crucial. Rune
Can you confirm this is the same issue as 202659? I believe this is already fixed in HEAD and 10-STABLE
I believe this is the same issue as 202659.
Agreed. I committed this fix a week ago or so. It's in HEAD and 10-STABLE and will be in FreeBSD 10.3 when that is released. *** This bug has been marked as a duplicate of bug 202659 ***