From owner-svn-src-head@freebsd.org Wed Apr 18 04:53:30 2018 Return-Path: Delivered-To: svn-src-head@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E8414F900A8; Wed, 18 Apr 2018 04:53:29 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "vps1.elischer.org", Issuer "CA Cert Signing Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 8D9177D781; Wed, 18 Apr 2018 04:53:29 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from Julian-MBP3.local (220-253-154-11.dyn.iinet.net.au [220.253.154.11]) (authenticated bits=0) by vps1.elischer.org (8.15.2/8.15.2) with ESMTPSA id w3I4rNRd029154 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Tue, 17 Apr 2018 21:53:26 -0700 (PDT) (envelope-from julian@freebsd.org) Subject: Re: svn commit: r332559 - head/usr.sbin/mountd To: Konstantin Belousov , Rick Macklem Cc: Andriy Gapon , "src-committers@freebsd.org" , "svn-src-all@freebsd.org" , "svn-src-head@freebsd.org" References: <20180417123212.GM1774@kib.kiev.ua> From: Julian Elischer Message-ID: Date: Wed, 18 Apr 2018 12:53:18 +0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: <20180417123212.GM1774@kib.kiev.ua> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Apr 2018 04:53:30 -0000 On 17/4/18 8:32 pm, Konstantin Belousov wrote: > On Tue, Apr 17, 2018 at 12:02:04AM +0000, Rick Macklem wrote: >> I wrote: >>> Julian Elischer wrote: >>>> On 16/4/18 6:56 pm, Konstantin Belousov wrote: >>> [stuff snipped] >>>>>> + ngroups =3D XU_NGROUPS + 1; >>>>> Why XU_NGROUPS and not the value of sysctl("kern.ngroups") ? >>>> valid question.. because that is how many are allocated? >>>> it was a "minimally invasive patch".. whoever used XU_NGROUPS before >>>> should have fixed it. >>>> Having said that, thanks for drawing out attention to it.. will >>>> probably fix. >>> 16 is the limit specified in the RFCs for Sun RPC, so that is the "on the wire" limit. >>> I haven't looked at the code. It might make sense to handle more here and then >>> set the limit at 16 after getting rid of duplicates, but I have no idea if = >>> it matters? >>> >>> rick >> Correcting my own post. Now that I've looked at the code, this doesn't go on >> the wire. It does go in the exports structure, which means that this structure >> would have to be revised (along with the syscall and VOP calls and the kernel >> code that uses it). These credentials are for the "maproot/mapall" export >> option and revising the export structure seems like quite a bit of work for this >> case. (Until revised XU_NGROUPS is the correct value to set it to, since there >> is a "struct xucred" in the exports structure.) >> >> Since Julian Elischer has been emailing me about adding a "fsid" export option >> which allows /etc/exports to set the FSID of the exported fs (which would also >> need to go in the exports structure), it might be about time to rev. the exports >> structure? > Probably yes, we would need a new variant of the nmount(2) syscall. > Existing syscall should use the old layout for compatibility (we care > about nmount and COMPAT32 as well). > our issue is that we make a server that combines CIFS/SMB access (via samba), credential setting from a company wide AD server (windows) via winbindd (samba) via nsswitch.. and NFS. The problem is that when one looks up a user name from the AD server One can get back a credential with a large number of groups, because some companies use windows groups extensively.  SO a sinel user may be in a group for every project they are involved with and a method of giving them access to files related to a project. In this scenario a group manager may be given access to a lot of groups. A user looking at a file via NFS needs to be able to see what he needs and still be blocked as per company policy. I am investigating the new user-manager  daemon may help but I don't fully understand it yet. I gather it maps an incoming request to a set of groups as defined on the server rather than on the client, but I'm not sure yet how that relates to mountd.