On Sep 7, 2010, at 4:58 PM, Olaf Kirch wrote:
> On Tuesday 07 September 2010 17:36:58 Chuck Lever wrote:
>> Probably not a bad idea. But I thought this was a problem for applications
>> that are calling rpcb_{un,}set(3t), not apps that are invoking the legacy
>> variants. How does this new patch address the problem?
>
> No, it's a problem with legacy apps calling pmap_set/unset. They simply
> stop working if you use pmap_set + libtirpc + portmap.
I think the crux of the problem is the latter half: libtirpc + portmap.
>> What happens if you try the other way around: try the AF_UNIX mechanism
>> first, then the legacy mechanism? It's arguable that any application
>> calling the pmap_{un,}set(3t) interface would likely expect the old
>> behavior anyway, but could probably benefit from the additional security
>> if rpcbind, rather than portmap, is running locally.
>
> I don't think apps coded to the old pmap_* interface will benefit
> in any way from the new security model. These services expect a
> root/non-root split of privilege, and that's what they get with
> PMAP_SET/UNSET, no matter whether they talk to rpcbind or portmap.
I haven't thought carefully about it, but that's probably correct.
>> 1. rpcb_{un,}set(3t) need to work whether rpcbind or portmapper are
>> running 2. pmap_{un,}set(3t) should still invoke rpcb_{un,}set(3t) under
>> the covers to ensure they get advanced security when available
>>
>> This is because you can build legacy apps against libtirpc (which want
>> robust pmap_{un,}set(3t) no matter which portmapper is running), but you
>> can also construct TI-RPC enabled apps that may be running on a system
>> with only portmap (which want robust rpcb_{un,}set(3t)). So I think you
>> have to fix both APIs.
>
> The latter is a problem indeed, and I guess we need to fix it as well.
> The one that I wanted to address first and foremost is applications
> using the legacy API
Yes, I agree both are a problem. The "rpcb_{un,}set(3t) + TI-RPC-enabled application running on a host with only portmap running" was the problem that was reported to me (twice, separately) a while ago.
--
chuck[dot]lever[at]oracle[dot]com
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
