This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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 04:46:32PM -0500, Chuck Lever wrote:
> The 16 group limit for AUTH_SYS is well known.  On Linux we happen to
> paper over it for user space applications using the glibc RPC
> implementation.  It's not a portable solution, but I believe that was
> all that was available when this implementation was written years ago.
...

> The problem is what do you do instead of crashing, in that case?
> Truncating the group list is a hidden bug as well.  Sending more than
> 16 groups is likely going to cause either a crash or truncation on the
> server end.  I seem to recall there was no clear way to return an
> error code through this particular RPC API, but I might be mistaken.

I understand there's an issue of "correctness" here, but in practice,
I think most users are better served by the approach taken in glibc --
truncate to 16 groups.  Suppose we defined 2 different functions in the
API -- one version that truncates at 16, and another version that throws
an error and refuses all access.  Which one would programmers be most
likely to use?

As you may know, the NFS software suffers from this same 16-group limitation.
I happen to belong to 20 supplemental groups.  As a result, the NFS
implementation denies me group privileges for the 4 groups that fall
beyond the 16-group cutoff.  But it honors my group privileges for
the first 16 groups.

Are you suggesting that the NFS implementation handles this incorrectly
and should instead deny me all NFS access?  It seems to me that this issue
was settled long ago by the prevalent behavior of truncating to 16 groups...

Regards,
Andy


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]