From owner-svn-src-all@FreeBSD.ORG Fri Dec 23 17:51:49 2011 Return-Path: Delivered-To: svn-src-all@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 433C0106566C; Fri, 23 Dec 2011 17:51:49 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id CE6F18FC1D; Fri, 23 Dec 2011 17:51:48 +0000 (UTC) Received: from alf.home (alf.kiev.zoral.com.ua [10.1.1.177]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id pBNHpiFD024927 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 23 Dec 2011 19:51:44 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: from alf.home (kostik@localhost [127.0.0.1]) by alf.home (8.14.5/8.14.5) with ESMTP id pBNHpiaP086645; Fri, 23 Dec 2011 19:51:44 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by alf.home (8.14.5/8.14.5/Submit) id pBNHphuS086644; Fri, 23 Dec 2011 19:51:43 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: alf.home: kostik set sender to kostikbel@gmail.com using -f Date: Fri, 23 Dec 2011 19:51:43 +0200 From: Kostik Belousov To: Alexander Kabaev Message-ID: <20111223175143.GJ50300@deviant.kiev.zoral.com.ua> References: <201112231500.pBNF0c0O071712@svn.freebsd.org> <201112231058.46642.jhb@freebsd.org> <201112231122.34436.jhb@freebsd.org> <20111223120644.75fe944d@kan.dyndns.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="eUJGivEzlkoRlQKE" Content-Disposition: inline In-Reply-To: <20111223120644.75fe944d@kan.dyndns.org> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-3.9 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org, Colin Percival , John Baldwin Subject: Re: svn commit: r228843 - head/contrib/telnet/libtelnet head/crypto/heimdal/appl/telnet/libtelnet head/include head/lib/libc/gen head/lib/libc/iconv head/lib/libc/include head/lib/libc/net head/libexec... X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Dec 2011 17:51:49 -0000 --eUJGivEzlkoRlQKE Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Dec 23, 2011 at 12:06:44PM -0500, Alexander Kabaev wrote: > On Fri, 23 Dec 2011 11:22:34 -0500 > John Baldwin wrote: >=20 > > On Friday, December 23, 2011 10:58:46 am John Baldwin wrote: > > > On Friday, December 23, 2011 10:00:38 am Colin Percival wrote: > > > > Author: cperciva > > > > Date: Fri Dec 23 15:00:37 2011 > > > > New Revision: 228843 > > > > URL: http://svn.freebsd.org/changeset/base/228843 > > > >=20 > > > > Log: > > > > Fix a problem whereby a corrupt DNS record can cause named to > > > > crash. [11:06]=20 > > > > Add an API for alerting internal libc routines to the presence > > > > of "unsafe" paths post-chroot, and use it in ftpd. [11:07] > > >=20 > > > Eh, the whole libc_dlopen() thing looks like a gross hack (and who > > > came up with that weird symbol name for a public API????). Is it > > > really even needed given the other fix to have ftpd drop privilege > > > before execing a helper program? I guess the main reason I don't > > > like it is it doesn't do anything to address the more general > > > problem. I would have expected instead something to restrict > > > dlopen() entirely including from other libraries than just libc in > > > certain circumstances. > >=20 > > At the very least if we feel that the libc_dlopen() thing is a > > temporary band-aid, we should move the new symbols into the private > > namespace so we can remove them once the better fix is in rather than > > being required to support them forever. libc_dlopen() is not exposed. The __FreeBSD_libc_enter_restricted_mode() is, and its name is ugly exactly to note the ugly intent. I do not see how the symbol can go int FBSDprivate_1.0 when it was supposed to be used by third-party applications. Putting this hack into rtld itself IMO has to wide consequences. For libc, we can enumerate the points that stop work after the call, but for the generic applications the consequences are undefined. > >=20 > > --=20 > > John Baldwin >=20 > Pardon for not catching that when I had a chance to influence the > outcome, but I would like to voice my support to tucking the ugliness > into private version namespace. >=20 > --=20 > Alexander Kabaev --eUJGivEzlkoRlQKE Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iEYEARECAAYFAk70v68ACgkQC3+MBN1Mb4giqACZASswqraasc/H8jXYcsVgrzHC E3YAnirjfVXolCKucgQmVK9PENC/Zp7c =yURB -----END PGP SIGNATURE----- --eUJGivEzlkoRlQKE--