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.
_______________________________________________
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
