On Fri, 23 Dec 2011 19:51:43 +0200 Kostik Belousov <kostik...@gmail.com> wrote:
> On Fri, Dec 23, 2011 at 12:06:44PM -0500, Alexander Kabaev wrote: > > On Fri, 23 Dec 2011 11:22:34 -0500 > > John Baldwin <j...@freebsd.org> wrote: > > > > > 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 > > > > > > > > > > Log: > > > > > Fix a problem whereby a corrupt DNS record can cause named > > > > > to crash. [11:06] > > > > > Add an API for alerting internal libc routines to the > > > > > presence of "unsafe" paths post-chroot, and use it in ftpd. > > > > > [11:07] > > > > > > > > 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. > > > > > > 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. > > > > > > -- > > > John Baldwin > > > > 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. > > > > -- > > Alexander Kabaev > 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. -- Alexander Kabaev
signature.asc
Description: PGP signature
