Date: Tue, 17 Apr 2018 15:32:12 +0300 From: Konstantin Belousov <kostikbel@gmail.com> To: Rick Macklem <rmacklem@uoguelph.ca> Cc: Julian Elischer <julian@freebsd.org>, 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: <20180417123212.GM1774@kib.kiev.ua> In-Reply-To: <YQBPR0101MB104243594E51285F229BC11FDDB00@YQBPR0101MB1042.CANPRD01.PROD.OUTLOOK.COM> References: <YQBPR0101MB104243594E51285F229BC11FDDB00@YQBPR0101MB1042.CANPRD01.PROD.OUTLOOK.COM>
next in thread | previous in thread | raw e-mail | index | archive | help
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).
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20180417123212.GM1774>