Re: [Libtirpc-devel] Fwd: Re: proposed patch to rpcbind to providefiner-grained security controls than offered by the -i option

[Chuck Lever <chucklever at gmail dot com>]

Hi Peter-

On Mon, Dec 20, 2010 at 12:50 PM,  <peter.staubach@emc.com> wrote:
> Hi.
>
> I disagree that the least surprising thing is to simply truncate the
> list. ?How does the user debug something which fails with some sort of
> access error, he looks to see if he is in the right group and is, but it
> still fails? ?Do we really expect the user to count down 16 groups in
> the list and figure out whether the correct group was in the first 16 or
> not? ?I don't think so.

Either an application fails to work because authunix_create_default()
fails outright, or it fails to work because the extra groups aren't in
the list.  I don't see much difference for the user in either case.

> The correct action is the definitive one, to fail operations which can't
> be correctly handled.

There actually isn't a definitive response to this issue.  The authors
of RFC 1831 and 5531 purposely left this behavior undefined.

>?This matches the expectations of most RPC
> applications which have been developed and expect to run in
> heterogeneous environments.

This particular interface is in libtirpc specifically for backwards
compatibility.  That alone means we should strongly consider adopting
the same behavior as glibc's authunix_create_default().  The fact that
the modern Solaris libtirpc version of authsys_create_default() also
truncates suggests that truncation is the expected behavior for this
particular legacy interface, and that changing the behavior of this
interface is more surprising than leaving it.

This interface is not the only way to create an AUTH_SYS
authenticator.  We are not removing the ability to handle the
supplemental groups list in any way the application desires: we still
provide authunix_create().  If it matters to the application, it will
use authunix_create() instead of authunix_create_default().  This is
exactly the fix that Jeff provided for nfs-utils last Spring.

Luckily, nfs-utils is still actively supported; some RPC applications
that use these legacy interfaces aren't, however.  Again, the goal
here is to facilitate easy porting from glibc.  We've documented more
than once that the new behavior of authunix_create_default() is
surprising and is not desired by application developers.    In fact,
it's been a trend that applications that don't tolerate the new
behavior are a problem precisely because they do not check for an
error return code.  Therefore, changing this legacy interface to fail
in new cases cannot improve matters.

authunix_create_default() has been around for a long time.  If we were
building from scratch, I would have more sympathy for your argument,
but here we have backwards compatibility to consider.  What's more, we
still provide a mechanism to handle it your way, in the form of
authunix_create().

-- 
"What is a pancake, if not a big, fluffy Eucharist?"
?-- Stephen Colbert