From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/4365 Path: news.gmane.org!not-for-mail From: Raphael Cohn Newsgroups: gmane.linux.lib.musl.general Subject: Re: ruserok et al Date: Wed, 4 Dec 2013 18:13:52 +0000 Message-ID: References: <20131204170507.GE24286@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=001a1133177c19ed1304ecb960d4 X-Trace: ger.gmane.org 1386180839 23375 80.91.229.3 (4 Dec 2013 18:13:59 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 4 Dec 2013 18:13:59 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-4369-gllmg-musl=m.gmane.org@lists.openwall.com Wed Dec 04 19:14:05 2013 Return-path: Envelope-to: gllmg-musl@plane.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1VoGxZ-0001We-7g for gllmg-musl@plane.gmane.org; Wed, 04 Dec 2013 19:14:05 +0100 Original-Received: (qmail 22446 invoked by uid 550); 4 Dec 2013 18:14:04 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Original-Received: (qmail 22438 invoked from network); 4 Dec 2013 18:14:04 -0000 X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=SBE7lELnXul2kloUTdZ+mrG/OxVeOTs5k02iogW1KrY=; b=EkmaKdmF64xLTWFW/9+sst6Y/EjurtwOmmTDhnC34PINaXfLwh0ax8c10AUjO7XE8j +QHDqbCl/iQJBBJRsLCfDIYJu3xsQY5jhejqfHBCEgO0BF8CKaODommANwKuuKeb/zoQ C4gw49k3L0k238TsEIlW2LZfrtKWSxTlr/LPOKi6Wc2aEWeEydh9yrp+R57vtsZ+RSIe sKbImDRPxfbfySKVer5YLdnde27ciXdxH3zTUCKTxVPMWVAZJbxV3RJztzKAgLPbPRbb uQnyQXALOb1jpB0hpQ7pO4P+mOe9WGe336qZWWlCVitnlxcLuko5WmPBuH0TL4qUFac+ 8ocA== X-Gm-Message-State: ALoCoQnMweJKtFSiXpqzrocGcASjv69IU1eZ5djZDS01dq9qXSy5HOwjVLv+sbZpIzW2ShxIhd8n X-Received: by 10.182.22.33 with SMTP id a1mr2432320obf.60.1386180832248; Wed, 04 Dec 2013 10:13:52 -0800 (PST) X-Originating-IP: [2001:8b0:862:b944:5e8:bd81:6ce5:582e] In-Reply-To: <20131204170507.GE24286@brightrain.aerifal.cx> Xref: news.gmane.org gmane.linux.lib.musl.general:4365 Archived-At: --001a1133177c19ed1304ecb960d4 Content-Type: text/plain; charset=UTF-8 I'm not sure I'll get anywhere with upstream... There's other dubious stuff in Linux PAM, too. Indeed a quick list of stuff that looks at least suspect to my mind is:- wheel (sudo et al are a better solution) userdb (why? Isn't /etc/passwd already a local database?) tally (defunct) time (obsolecent; why restrict logins to certain times in this day and age when not using time shared systems and dial up) pwhistory (stores previous passwords ?potentially recoverably) permit (insecure) nologin (security risk; forces root to be special) mail (old-fashioned and of limited use in a server or desktop today) group (security risk; unnecessary extra complexity in addition to /etc/group) ftp (in 2013? And it reckons it's easily spoofed in its own man page) debug (unnecessary) but none of that has to do with musl (although dropping time means there's less patching to do to support legacy NIS junk)... Anyway, now I'm off-topic. On 4 December 2013 17:05, Rich Felker wrote: > 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 > --001a1133177c19ed1304ecb960d4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I'm not sure I'll get anywhere with= upstream... There's other dubious stuff in Linux PAM, too. Indeed a qu= ick list of stuff that looks at least suspect to my mind is:-

wheel = (sudo et al are a better solution)
userdb (why? Isn't /etc/passwd already a local database?)
tally (def= unct)
time (obsolecent; why restrict logins to certain times in this day= and age when not using time shared systems and dial up)
pwhistory (stor= es previous passwords ?potentially recoverably)
permit (insecure)
nologin (security risk; forces root to be special)
= mail (old-fashioned and of limited use in a server or desktop today)
gro= up (security risk; unnecessary extra complexity in addition to /etc/group)<= br> ftp (in 2013? And it reckons it's easily spoofed in its own man page)debug (unnecessary)

but none of that has to do with musl (al= though dropping time means there's less patching to do to support legac= y NIS junk)...

Anyway, now I'm off-topic.


On 4 December 2013 17:0= 5, Rich Felker <dalias@aerifal.cx> wrote:
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 trie= s 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 legac= y '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 eithe= r:-
> - return the failure outcome;
> - or, return a nasty warning and a failure outcome? And a syslog on ru= ntime
> 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

--001a1133177c19ed1304ecb960d4--