From owner-svn-src-head@FreeBSD.ORG Fri Dec 23 18:30:05 2011 Return-Path: Delivered-To: svn-src-head@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 778291065670; Fri, 23 Dec 2011 18:30:05 +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 DD71B8FC0C; Fri, 23 Dec 2011 18:30:04 +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 pBNIU0W6027215 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 23 Dec 2011 20:30:00 +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 pBNIU0xG086841; Fri, 23 Dec 2011 20:30:00 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by alf.home (8.14.5/8.14.5/Submit) id pBNITxck086838; Fri, 23 Dec 2011 20:29:59 +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 20:29:59 +0200 From: Kostik Belousov To: Alexander Kabaev Message-ID: <20111223182959.GL50300@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> <20111223175143.GJ50300@deviant.kiev.zoral.com.ua> <20111223132034.12192baa@kan.dyndns.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="jviMX/jurV6/I2v0" Content-Disposition: inline In-Reply-To: <20111223132034.12192baa@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-head@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Dec 2011 18:30:05 -0000 --jviMX/jurV6/I2v0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Dec 23, 2011 at 01:20:34PM -0500, Alexander Kabaev wrote: > On Fri, 23 Dec 2011 19:51:43 +0200 > Kostik Belousov wrote: >=20 > > 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. > >=20 > > 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 > >=20 > Putting symbol into official namespace implies that we are willing to > provide and maintain it forever, which I do not think was the intent > for the function in question. FBSD_PRIVATE says nothing about who > should and should not link to it, only the level of API stability one > has to expect in the end. If/when we have better security mechanisms > (capsicum?) available to users by default, this should be ripped out > with extreme prejudice. The API is offered as a solution to third-parties. Telling them to use the API that is known to be broken in future is wrong step for the project, IMO. I doubt that proftpd will 'go capsicum'. --jviMX/jurV6/I2v0 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iEYEARECAAYFAk70yKcACgkQC3+MBN1Mb4h5cACfRdeJDJqjh9/7vDBddpb9DZ43 tVsAoI5tO5GPH5Lloc6O1tgTzyzWoE3B =4Zcb -----END PGP SIGNATURE----- --jviMX/jurV6/I2v0--