Why is www's $PATH only /usr/bin:/bin?

[Niklaas Baudet von Gersdorff]

Thanks for all the replies and explanations.

Bertram Scharpf [2016-04-27 14:07 +0200] :

> On Tuesday, 26. Apr 2016, 21:40:48 +0200, Niklaas Baudet von Gersdorff wrote:
> I recommend to include a line into your Apache configuration
> (or whichever HTTP server you use) like
> 
>   SetEnv PATH /sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin:/usr/local/bin

I use NGINX but there should be some way to do that there too.

RW via freebsd-questions [2016-04-27 13:33 +0100] :

> On Wed, 27 Apr 2016 14:07:04 +0200
> Bertram Scharpf wrote:
> 
> 
> > I wondered as well about this behaviour sometimes. The
> > default path from login.conf will be set at login. Yet, the
> > www daemon is started from rc and this is not understood to
> > be a login. The perverse thing is that when you do a
> > "/usr/local/etc/rc.d/apache24 restart" from the command
> > line, then the PATH variable will contain the value you
> > expect.
> 
> Avoiding that is one of the reasons why service(8) exists.

Thanks for pointing that out. I did not know that either.

Steve O'Hara-Smith [2016-04-27 08:21 +0100] :

> On Tue, 26 Apr 2016 21:40:48 +0200
> Niklaas Baudet von Gersdorff <stdin at niklaas.eu> wrote:
> 
> > Hi,
> > 
> > I figured that www's $PATH is only /usr/bin:/bin. Why is that if
> > /etc/login.conf says the following?
> > 
> >     default:\
> >     --------8<--------
> >         :path=/sbin /bin /usr/sbin /usr/bin /usr/games /usr/local/sbin /usr/local/bin
> > ~/bin:\
> >     --------8<--------
> 
> 	I assume you mean this is the path available to CGI or similar
> running under a web server. If so then the reason for the discrepancy is at
> least in part that user www never logged in ...
> 
> > /etc/passwd looks like this.
> > 
> >     www:*:80:80:World Wide Web Owner:/nonexistent:/usr/sbin/nologin
> 
> 	... and indeed cannot log in so the login.conf is not going to
> apply. It is also possible (indeed likely) that the web server deliberately
> minimises the path passed to CGI scripts for security.

Makes sense. Thank you for the explanation! I was not aware of that.

> > So, I left everything the default.
> > 
> > The thing is that I want to run something in /usr/local/bin with PHP's
> > 
> >     shell_exec($cmd);
> > 
> > but that's not working because it's not in $PATH.
> > 
> > Any hint is very much appreciated.
> 
> 	It should be possible to adjust the path seen by PHP in the PHP
> config.

I will try PHP's configuration first. If that's not possible, I'll go for the
configuration of NGINX.

Luca Ferrari [2016-04-27 10:22 +0200] :

> On Wed, Apr 27, 2016 at 9:21 AM, Steve O'Hara-Smith <steve at sohara.org> wrote:
> > On Tue, 26 Apr 2016 21:40:48 +0200
> >         ... and indeed cannot log in so the login.conf is not going to
> > apply. It is also possible (indeed likely) that the web server deliberately
> > minimises the path passed to CGI scripts for security.
> 
> Exactly. You have to think that PATH can be changed by the running
> process, so there is no surprise that is either expanded or shrinked.
> 
> >> The thing is that I want to run something in /usr/local/bin with PHP's
> >>
> >>     shell_exec($cmd);
> >>
> >> but that's not working because it's not in $PATH.
> 
> I would suggest to either add the path to the php config or to make a
> php function to build the absolute path for command based on your
> installation or some other condition. That would make the application
> portable.

In NGINX's configuration it's possible to change php.ini settings for
particular server processes. I'll go for that. If that's not possible I'll try
to spawn a separate php-fpm process that configured the way I need it. And if
that's not possible I'll hardcode a function in PHP.
    
    Niklaas