svn commit: r268641 - head/usr.sbin/service

[dteske at FreeBSD.org]

> -----Original Message-----
> From: Jordan Hubbard [mailto:jordanhubbard at me.com]
> Sent: Tuesday, July 15, 2014 9:39 PM
> To: dteske at freebsd.org
> Cc: Mateusz Guzik; Bryan Drewery; src-committers at freebsd.org; svn-src-
> all at freebsd.org; svn-src-head at freebsd.org
> Subject: Re: svn commit: r268641 - head/usr.sbin/service
> 
> On Jul 15, 2014, at 7:13 PM, dteske at 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'
> "launch contract" was one of the best decisions we ever made at Apple.
> 
> The Unix process environment is a septic tank, and that's actually being
kind
> since most septic tanks don't 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're wrong.  Not because there aren't some
> extremely smart Unix people in the audience, but because it's 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's behavior
> in unpredictable ways.   Even if the intention isn't to be hostile, you
can still
> cause some truly Heisenbergian results by having the environment be
> unpredictable in nature.
> 
> It may not be "Unixy", but Unix didn't 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's 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.
> 

Odd indeed. An rc.d script needs to know $TERM so it can launch a background
instance of screen or tmux. The rc.d script itself doesn't use $TERM but the
instance of screen or tmux needs it else it thinks you're not on a terminal
(maybe
the proper thing is to patch screen and tmux ;D).
-- 
Devin