sys/rpc: UNIX auth: Use AUTH_SYS_MAX_{GROUPS,HOSTNAME} as limits (1/2)

[olce]

Summary

Consistently with the XDR_INLINE() variant of xdr_authunix_parms()
(_svcauth_unix() in 'svc_auth_unix.c'), reject messages with credentials
having a machine name length in excess of AUTH_SYS_MAX_HOSTNAME or more
than AUTH_SYS_MAX_GROUPS supplementary groups, which do not conform to
RFC 5531. This is done mainly because we cannot store excess groups
anyway, even if at odds with the robustness principle ("be liberal in
what you accept").

Fixes: dfdcada31e79 ("Add the new kernel-mode NFS Lock Manager.")
Sponsored by: The FreeBSD Foundation

[rmacklem]

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

sys/rpc/authunix_prot.c

63–64

These xdr functions usually have a case where
xdrs->x_op is XDR_FREE.

Maybe adding a KASSERT to check that x_op != XDR_FREE
might be useful?

[olce]

sys/rpc/authunix_prot.c

63–64

I've noticed the existence of XDR_FREE recently. If the function does not support anything else than encode and decode, let's indeed test for that. It doesn't look like it would be too hard to implement XDR_FREE, as basically this function does not allocate anything on XDR_DECODE, so we basically could just return TRUE immediately. I don't see any caller with XDR_FREE in the kernel anyway (I see some in userland to the userland version).

[rmacklem]

sys/rpc/authunix_prot.c

63–64

Yep, you can implement it if you'd like.
As you note, there are no callers. It would
break if there were.