Re: ruserok et al

[Rich Felker <dalias@aerifal.cx>]

On Wed, Dec 04, 2013 at 02:12:31PM +0000, Raphael Cohn wrote:
> Dear List,
> 
> Whilst compiling pam_rhosts in Linux PAM 1.1.8 (pam_rhosts.c), it tries to
> use the function 'ruserok'. I believe this, and its siblings, aren't in

This is part of the legacy rhosts API for source-IP-address-based
authentication. It's useless, dangerous, and really disturbing that
PAM even supports something that was obsolete and known-dangerous a
decade before PAM was invented... My first reaction would be to say
"patch it out and send a bug report upstream".

> musl. Quite correctly, I suspect - I presume these relate to the legacy 'r'
> commands that no one in their right mind should be using. I'll be patching
> my installation to remove this module from the build (*sigh* Linux pam
> doesn't make choosing a subset of modules easy).

Yes, this is the right solution, but we should try (diplomatically :)
to get upstream fixed too.

> Would it make sense, for completeness to add stubs to musl to do either:-
> - return the failure outcome;
> - or, return a nasty warning and a failure outcome? And a syslog on runtime
> use to really give users a kick?

A stub that just returns failure would not be such a bad thing, but
when it's such a harmful a function that only a single package has
been caught using, I'd rather try to get it fixed upstream.
Compatibility with broken apps/libs is a continuous stream of choices
whether to work around the brokenness in musl (often this has tiny
marginal cost but that cost builds up over time with lots of broken
packages) or make the efforts to get the upstream fixed.

> Alternatively, it might be a good idea to not do this, but have a wiki page
> somewhere listing deliberately unimplemented and stub functions.

That might be a good idea anyway even if we don't add more such
functions.

Rich