Date: Fri, 5 Jan 2007 16:47:20 -0500 From: Garance A Drosehn <gad@FreeBSD.org> To: Mike Pritchard <mpp@mppsystems.com>, Yar Tikhiy <yar@FreeBSD.org> Cc: cvs-src@FreeBSD.org, src-committers@FreeBSD.org, cvs-all@FreeBSD.org Subject: Re: cvs commit: src/etc rc.subr Message-ID: <p06240805c1c463b5bcab@[128.113.24.47]> In-Reply-To: <20061231170411.GA53408@mail.mppsystems.com> References: <200612311107.kBVB7TrP042343@repoman.freebsd.org> <20061231170411.GA53408@mail.mppsystems.com>
next in thread | previous in thread | raw e-mail | index | archive | help
At 11:04 AM -0600 12/31/06, Mike Pritchard wrote: >On Sun, Dec 31, 2006 at 11:07:29AM +0000, Yar Tikhiy wrote: >> yar 2006-12-31 11:07:29 UTC >> >> FreeBSD src repository >> >> Modified files: >> etc rc.subr >> Log: >> Allow for /usr/bin/env when parsing the shebang line from an >> interpreted $command. Some "portable" sofware packages use such a >> line to skip the task of figuring out the absolute pathname of the >> interpreter at install time, e.g.: >> >> #!/usr/bin/env python >> >> It is insecure, but a popular book on Python seems to have advised >> it to a wide audience. Hence a number of such scripts in the ports, >> mostly written in Python. > >If it's insecure, than why allow it? If the ports need a patch to >make it secure, then they should be patched. The commit-comment makes the change sound more scary than it really is. And while I am a little surprised that nothing seems to set a value for PATH in the /etc/rc.d/* scripts, I do see that: /etc/rc:PATH=/sbin:/bin:/usr/sbin:/usr/bin /etc/rc:export HOME PATH /etc/rc.shutdown:PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin /etc/rc.shutdown:export HOME PATH So, running some script via /usr/bin/env is not an issue during the normal startup and shutdown operations. I guess it theoretically might be an issue when people run a /etc/rc.d/<whatever> file by hand, as root, and only if they have already set a dangerous value for PATH. I.e, that administrator *already* has a security issue, and using /usr/bin/env merely means the startup line in some /etc/rc.d/* scripts are not protected from that already-existing security problem. However, this change doesn't actually run anything with /usr/bin/env. It only makes rc.subr work reliably for those scripts which have decided to use /usr/bin/env. On the flip side, the /usr/bin/env trick is explicitly recommended for the perl and ruby communities, in addition to python. The practice is described in multiple books for those languages. It is by far the easiest way to write a portable script. In this case, "portable" also covers scripts which are only running a variety of FreeBSD configurations. It isn't just a matter of portability between FreeBSD vs Linux vs Solaris. It could get quite tricky to write a script which is certain to get the right version of python on every installation of FreeBSD. (This is more of an issue for python and ruby than perl. Perl used to be part of the base system, so we have the special /usr/bin/perl link even when perl is installed from ports. We do not create a special link like that for ruby or python). Yar's comment may have made this change sound scary, but in practice the security exposure for this specific change is zero. I understand what Yar was thinking of when he mentioned it the way he did, but the change itself does not cause any security problem. None. Zero. -- Garance Alistair Drosehn = drosehn@rpi.edu Senior Systems Programmer or gad@FreeBSD.org Rensselaer Polytechnic Institute; Troy, NY; USA
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?p06240805c1c463b5bcab>