On Mon, 4 Dec 2017, J. Bruce Fields wrote:
On Mon, Dec 04, 2017 at 01:39:37PM -0200, Thiago Rafael Becker wrote:
On Mon, 4 Dec 2017, NeilBrown wrote:
I think you need to add groups_sort() in a few more places.
Almost anywhere that calls groups_alloc() should be considered.
net/sunrpc/svcauth_unix.c, net/sunrpc/auth_gss/svcauth_gss.c,
fs/nfsd/auth.c definitely need it.
So are any other functions that modify group_info. OK, I think I'll
implement the type detection below as it helps detecting where these
situations are located.
This may take some time to make sane. I wonder if we shouldn't
accept the first change suggested to fix the corruption detected in
auth.unix.gid while I work on a new set of patches. Also, that patch
doesn't change behavior of set_groups, and is easier to backport if
distros relying on older kernels need to do so and change behavior.
The first suggestion is undergoing tests, and so far we didn't
detect any new corruptions on auth.unix.gid.
I'm a little confused--we can remedy the oversight Neil points out just
by adding a few more group_sort()s, and that shouldn't be hard, right?
I'd be OK with doing that first and then adding a code to enforce the
sorting second.
Ok. Sending a new set. The set will cover all calls to group_alloc, after
the function has ended filling the groups.
--b.
Maybe it could be done with types.
I changed the interfaces on groups_{alloc,sort} to check. There are
some extra changes needed in groups_from_user and others to make
this viable, but I like it and I'll try to make it happen.
Thanks,
NeilBrown
Thanks,
trbecker
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html