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 5:23 PM, Andrew J. Schorr
<ajschorr@alumni.princeton.edu> wrote:
> 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...
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.
--
"What is a pancake, if not a big, fluffy Eucharist?"
?-- Stephen Colbert