svn commit: r332559 - head/usr.sbin/mountd

[Julian Elischer]

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.