This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [Libtirpc-devel] Fwd: Re: proposed patch to rpcbind to providefiner-grained security controls than offered by the -i option
On Sat, Dec 18, 2010 at 05:33:54PM -0500, Chuck Lever wrote:
> If there is a common solution to this issue among RPC implementations,
> then we should adopt that.
>
> The discussion we had 9 months ago was among a former Sun NFS
> engineer, a CIFS developer, and myself (10 years of experience with
> the Linux NFS and RPC implementations in user space and in the
> kernel). Either we were not aware that truncation is the prevalent
> behavior, or we decided at the time that truncation was just as
> incorrect as failing outright.
>
> But we can look into it again, as I said.
I certainly don't claim to be an expert. My understanding (which could
be flawed) is that NFS has traditionally handled this issue by
truncating to 16 groups. One can google for NFS 16 groups, and there
are many hits discussing this behavior. And truncation is obviously how
glibc handles it. If the goal is to replace the glibc implementation
with tirpc, then it seems rather dangerous to me to break various applications
that used to work under glibc...
As I mentioned, if there's doubt, let's just add both functions to the API and
let programmers choose. My guess is that most would choose the version that
truncates to 16 groups instead of crashing.
Regards,
Andy