Date: Wed, 18 Apr 2018 12:53:18 +0800 From: Julian Elischer <julian@freebsd.org> To: Konstantin Belousov <kostikbel@gmail.com>, Rick Macklem <rmacklem@uoguelph.ca> Cc: Andriy Gapon <avg@FreeBSD.org>, "src-committers@freebsd.org" <src-committers@freebsd.org>, "svn-src-all@freebsd.org" <svn-src-all@freebsd.org>, "svn-src-head@freebsd.org" <svn-src-head@freebsd.org> Subject: Re: svn commit: r332559 - head/usr.sbin/mountd Message-ID: <ab24ee87-22f7-d40c-5807-d8a3ed996e54@freebsd.org> In-Reply-To: <20180417123212.GM1774@kib.kiev.ua> References: <YQBPR0101MB104243594E51285F229BC11FDDB00@YQBPR0101MB1042.CANPRD01.PROD.OUTLOOK.COM> <20180417123212.GM1774@kib.kiev.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?ab24ee87-22f7-d40c-5807-d8a3ed996e54>