Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 15 Jul 2014 21:39:19 -0700
From:      Jordan Hubbard <jordanhubbard@me.com>
To:        dteske@freebsd.org
Cc:        svn-src-head@freebsd.org, svn-src-all@freebsd.org, Mateusz Guzik <mjguzik@gmail.com>, src-committers@freebsd.org, Bryan Drewery <bdrewery@FreeBSD.org>
Subject:   Re: svn commit: r268641 - head/usr.sbin/service
Message-ID:  <BFE7BE40-DF31-4AAA-9B34-6B696744F212@me.com>
In-Reply-To: <011a01cfa09b$928b4710$b7a1d530$@FreeBSD.org>
References:  <201407150218.s6F2Itj8044531@svn.freebsd.org> <53C56BE9.9050304@FreeBSD.org> <20140715191553.GA31990@dft-labs.eu> <011a01cfa09b$928b4710$b7a1d530$@FreeBSD.org>

next in thread | previous in thread | raw e-mail | index | archive | help
On Jul 15, 2014, at 7:13 PM, dteske@freebsd.org wrote:

> I would argue that not all programs are going to like having
> a nearly empty environment. Things like TERM and SHLVL
> at the very least should be passed (after-all, the boot process
> takes place on [a] a terminal and [b] in a shell).

Having launchd scrub every processes environment down to nothing, then =
have environment variables be set explicitly as part of that processes=92 =
=93launch contract=94 was one of the best decisions we ever made at =
Apple.

The Unix process environment is a septic tank, and that=92s actually =
being kind since most septic tanks don=92t also contain bottles of nerve =
gas and the occasional live hand grenade.  Many parts of the environment =
are trivially attackable, and if anyone on the CC line thinks they know =
the full extent of that attack surface, they=92re wrong.  Not because =
there aren=92t some extremely smart Unix people in the audience, but =
because it=92s simply impossible to know how each and every environment =
variable will be used, how it can overflow, or how it can be used to =
permute a program=92s behavior in unpredictable ways.   Even if the =
intention isn=92t to be hostile, you can still cause some truly =
Heisenbergian results by having the environment be unpredictable in =
nature.

It may not be =93Unixy=94, but Unix didn=92t grow up in a world with =
millions of instances of itself or the big, bad Internet encompassing =
pretty much every country on earth.  Changes need to be made to keep up =
with the times, and you can rest assured that FreeBSD=92s competition is =
making those changes or has already made them.

I also find it a frankly weird assertion that a background service would =
care about the value of TERM.  That sounds like a pretty warped service =
to me, since assuming interactivity is more the exception than the rule =
these days.

- Jordan




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?BFE7BE40-DF31-4AAA-9B34-6B696744F212>