Reword the line to say "performs case insensitive lookups,"
as suggested by kib@.

In D53368#1218929, @markj wrote:

There is a similar pattern in nfsrpc_writeds(). Does that need to be fixed too?

Add the same fix to nfsrpc_writeds().

Oh, and it needs the date to be updated.

Looks ok to me. I'll leave min vs MIN up to you.

Looks ok to me. You can decide whether or not to add the
KASSERT for x_op != XDR_FREE?

Looks fine to me. Feel free to ignore the minor comments.

In D52970#1210155, @cy wrote:

In D52970#1210136, @rmacklem wrote:

Looks fine to me. Is there somewhere that we can stick
examples for krb5.conf, kdc.conf and kadm5.acl?

In share/examples/krb5 maybe?

Looks fine to me. Is there somewhere that we can stick
examples for krb5.conf, kdc.conf and kadm5.acl?

Just fyi. Unless I hear otherwise I am going to commit
this patch Monday, so that it can be MFC'd to stable/15.
It stops rpcbind from crashing. If others don't like the
choice of address string for netlink, that can be changed
later.

In D52651#1203905, @glebius wrote:

What code does call into this function with netlink argument? IMHO, this transport layer abstraction of RPC is a big code bloat where most of the code is never executed. Of course a crash if it happens needs to be fixed.

In D52651#1203905, @glebius wrote:

What code does call into this function with netlink argument? IMHO, this transport layer abstraction of RPC is a big code bloat where most of the code is never executed. Of course a crash if it happens needs to be fixed.

In D52263#1194959, @olce wrote:

In D52263#1194857, @olce wrote:

So, while I'm here, I'd also like to know what you think about discarding groups exceeding the NGROUPS limit.
(snip)

According to RFC 5531, the authsys_parms structure for AUTH_SYS contains in fact the effective group ID (spelled out exactly like this in the RFC) and then an array of 16 groups "that contain the caller as a member". But we only have XU_NGROUPS (16) in total in struct xucred.

So, what do you think of:

1. To support the protocol, we accept up to 17 groups (1 + 16), but no more (extensions are not supported).
2. But we discard the 17th one, as we don't have room to store it.

This is in fact what the inline decode version is already doing.

I made a few comments, but stopped there.
You seem to be confusing the 16 which is
a hardwired RPC constant with what happens
to be defined elsewhere.
(Even if XU_NGROUPS == 16 there is nothing
stopping someone from changing that someday.)

I'll admit I do not understand what your recent gid
changes are, so I will resign as a reviewer.

Looks fine to me.

In D51845#1184637, @rmacklem wrote:

In D51845#1184634, @markj wrote:

The not so good news is that this bug made it out into 14.3.

I'll submit an EN since this is my bug (unless you'd really like to).

You are more than welcome to do so.
I'll give it a 2week MFC and you'll see it go into stable/14 in two weeks.