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>
index | next in thread | previous in thread | raw e-mail
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).
home |
help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20180417123212.GM1774>