Date: Thu, 29 Dec 2011 14:00:41 -0500 From: John Baldwin <jhb@freebsd.org> To: d@delphij.net Cc: freebsd-security@freebsd.org, Doug Barton <dougb@freebsd.org> 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... Message-ID: <201112291400.41075.jhb@freebsd.org> In-Reply-To: <4EFCB4F1.2050500@delphij.net> References: <201112231500.pBNF0c0O071712@svn.freebsd.org> <201112291343.02248.jhb@freebsd.org> <4EFCB4F1.2050500@delphij.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thursday, December 29, 2011 1:44:01 pm Xin Li wrote: > On 12/29/11 10:43, John Baldwin wrote: > > On Thursday, December 29, 2011 1:26:17 pm Xin Li wrote: > >> On 12/29/11 06:39, John Baldwin wrote: > >>> Can you give some more details on why ftpd is triggering a > >>> dlopen inside of the chroot? It would appear that that is > >>> unrelated to helper programs (since setting a flag in libc in > >>> ftpd can't possibly affect helper programs ability to use > >>> dlopen() from within libc). > >> > >> Sure. That's because nsdispatch(3) would reload > >> /etc/nsswitch.conf if it notices a change. After chroot() the > >> file is considered as "chang"ed and thus it reloads the file as > >> well as designated shared libraries. > > > > But ftpd has to be doing some operation that invokes an nss lookup > > after entering the chroot for that to trigger, correct? > > Oh ok, that was the built-in ls(1). Were we not able to drop privilege before doing that? I.e. if you forked a new process that dropped privilege before doing the ls (similar to if you were to exec /bin/ls as a helper), would that not have fixed this? -- John Baldwin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201112291400.41075.jhb>