Re: Re: Some fun with tcp_wrappers

[wietse () porcupine org (Wietse Venema)]

Tomas Hoger:
> Hi Wietse!
>
> On Thu, 16 Apr 2009 07:59:20 -0400 (EDT) wietse () porcupine org (Wietse
> Venema) wrote:
>
> > Tomas Hoger:
> > > The good_client (tcp_wrappers wrapping function in portmap /
> > > nfs-utils / ...) problem is rather interesting too, as it creates
> > > problems due to its attempt to avoid unneeded DNS lookups
> > > (workaround for hosts_ctl limitation?) and support host aliases
> > > (tcp_wrappers limitation).  
> >
> > See my previous email. Programs such as portmappers must not look
> > up hostname information, since that would result in an infinite
> > recursion when host lookups use SUNRPC services. To state the
> > obvious: the portmapper would directly or indirectly send SUNRPC
> > calls to itself, in order to locate the NIS server.
>
> Thank you for pointing this problem out.  And my apologies for not
> digging deep enough into peculiarities of RPC and making a conclusions
> based on the code already used in the wild.  It seems that portmappers
> do name resolution, even if they should not.
>
> Current upstream portmap code has a compile-time option that enables
> name resolution (along with proper warnings):
>   http://neil.brown.name/git?p=portmap;a=commitdiff;h=b663f78b86
>
> but the variants of this (buggy) patch without such ENABLE_DNS define
> and proper warnings are used in the wild.  Additionally, portmap also
> has an explicit check for local access and does not call tcp_wrappers
> at all in such case, probably to avoid the problem you have mentioned.
> Is there a case when even that is insufficient?

I worked last on this program 13 years ago. If I recall correctly
the from_local() test will avoid certain screwups, but a full
analysis will take time, and I am short on that.

        Wietse

> > Before discussing changes to a program, it is a good investment of
> > time to find out how the program works, and why it works in the
> > specific way it works.
>
> I obviously erred on this!  Though with code being copied across
> projects, getting changes that are not always correct, or copying
> special handling to projects where it is not needed, makes it rather
> complicated to not miss some whys or always distinguish correct changes
> from incorrect ones.  Nobody has perfect knowledge of everything, that's
> when objective feedback from subject experts is greatly appreciated and
> desired to not miss any gotchas and have all pros and cons to make the
> decision.