Bug 97604 - Clear environment for init scripts (was: Bad BASH_ENV causes Permission Denied in CGI scripts.)
Clear environment for init scripts (was: Bad BASH_ENV causes Permission Denie...
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: initscripts (Show other bugs)
12
All Linux
high Severity medium
: ---
: ---
Assigned To: Bill Nottingham
bzcl34nup
: FutureFeature, Triaged
Depends On:
Blocks: FC5Target
  Show dependency treegraph
 
Reported: 2003-06-18 06:09 EDT by Behdad Esfahbod
Modified: 2014-03-16 22:36 EDT (History)
7 users (show)

See Also:
Fixed In Version: systemd-15-1.fc15, initscripts-9.22-1.fc15
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2010-11-30 21:56:22 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Behdad Esfahbod 2003-06-18 06:09:43 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20030225

Description of problem:
I wonder if it is an httpd issue.  When the httpd is started by root, there is
an enviromental variable BASH_ENV set to /root/.bashrc.  As no one alters it, it
gets into the httpd processes.  When you run a PHP page which runs a shell
script (for example by using backticks), the bash errors by bash: /root/.bashrc:
Permission denied.

The problem can be solved in some levels.  One is that PHP takes care, but
better Apache does.  Apache can change BASH_ENV to ~apache/.bashrc, and a new
file ~apache/.bashrc (which expands to /var/www/.bashrc) should be added.

The solution I have made is to unset BASH_ENV in /etc/init.d/httpd.
The same problem may arise in other daemons that change to a safe user, and
allow users to run shell scripts from inside.

Version-Release number of selected component (if applicable):
httpd-2.0.40-21.3

How reproducible:
Always

Steps to Reproduce:
1. Create a x.php containting these:
<?php echo `./x.sh 2>&1`; ?>
2. Create a x.sh containing these:
#!/bin/bash
echo test
3. Run the PHP file through web server.
    

Actual Results:  I got:
bash: /root/.bashrc: Permission denied
test

Expected Results:  test

Additional info:

I don't know how this problem was handled in previous versions.  I feel that
Apache 1.3 used to take care of this.

As the fix is so trivial, and it really stops many PHP applications from
running, I recommend that the fix is released ASAP.
Comment 1 Joe Orton 2003-06-18 06:46:19 EDT
How are you starting httpd? This should not be a problem if you use:

  # service httpd start

since the initscript is executed using "env -i", with a completely empty
environment.
Comment 2 Behdad Esfahbod 2003-06-18 07:41:30 EDT
I started it with switching run level, by `init 3` for example.  So I just found
that the new `service` scripts does something useful.

I think the same thing (env...) should be done in /etc/rc.d/rc too.

One other thing:  Almost anyone I know still uses /etc/init.d/* to control the
services manually.  The drawback of using `service' is no tab completion for the
service name.  It can be solved by creating symlinks named service-httpd ... to
/sbin/service, and ask service to handle them.  It is a good idea in my opinion,
as is more like the redhat-config-* scripts.
Comment 3 Joe Orton 2003-06-18 09:24:33 EDT
It does seem like env -i should be used in either the daemon() function of
/etc/init.d/functions or in /etc/rc.d/rc rather than adding it every daemon's
init script.  Bill would you agree?
Comment 4 Behdad Esfahbod 2003-06-18 09:33:27 EDT
It would better go into daemon(), to do the work for manual starts by
/etc/init.d/* [re]start.
Comment 5 Bill Nottingham 2003-06-18 14:50:04 EDT
I can see doing it in either 'rc' or in the daemon function. I'm sure there's
some daemon overriding the environment somehow that needs it not cleaned in
daemon(), though.
Comment 6 David Johnston 2003-10-30 22:46:30 EST
I see two problems here.  First, the irritation factor of having "service foo"
behave differently from "/etc/init.d/foo".  Second, the security implications of
not starting all daemons with a clean environment.

In my mind, the less serious problem of having "service foo" behave differently
from "/etc/init.d/foo" is reason enough to fix daemon(), even understanding that
some initscripts might need fixing up to deal with the fact that they don't have
a default environment any more.

That said, the security and reliability implications of not starting daemons
with a clean environment spook me.  I could see an inexperienced admin changing
something innocuous in the default environment (LOCALE, for example) that might
cause a badly written daemon to misbehave in ways that weren't ever tested. 
"Badly written daemon" would, in my book, include any daemon that needs
something set in its environment.  I vaguely recall a remote exploit that worked
just like this under another OS (AIX, I think, but it might have been VMS).

I would flag this as "security."  Also, I see that this problem presents all
manner of complications, since it may force you to patch the initscripts of
other programs, and you will have to explain the change in advance so that
admins can patch local initscripts. 
Comment 7 David Johnston 2003-10-31 11:33:26 EST
Oops, found a quirk in Bugzilla.  If you add a command and click "Add Me to Cc
List", everyone on the Cc list gets excluded from the notification message for
the additional comments.  I've filed a bug against Bugzilla for this.
Comment 8 Behdad Esfahbod 2004-01-18 05:55:00 EST
It's getting too late to solve this.  I've come to a solution, which I
myself do not like it actually, but it's better than letting it go
unsolved.

It is the first line of almost any init script to source
/etc/rc.d/init.d/functions, so we just rerun ourselves from inside
functions with a clean environment.  If this is not acceptable, we can
clean the environment inside 'functions', but it takes a few cycles.

I'm almost sure the second approach is good enough to get in.
Comment 9 Behdad Esfahbod 2004-01-19 02:20:45 EST
With my proposed method of changing 'functions', scripts that need to
be fixed are those with [F1UP] in this message:

http://www.redhat.com/archives/fedora-devel-list/2004-January/msg01015.html
Comment 10 Joe Orton 2004-06-23 09:41:35 EDT
Probably a good time to revisit this now, early in the FC3 cycle.

Do you have a patch to functions which can be tried, Behdad?
Comment 11 Gunther Schlegel 2004-11-05 03:12:00 EST
I seem to have that problem with shell scripts started by xinetd in
2.1WS and find it very annoying.
Comment 12 Joe Orton 2005-10-03 07:28:17 EDT
Thinking about this in the cold light of day, it would seem infeasible to clear
the environment in daemon() since it is necessary for daemons to be able to set
arbitrary environment variables (and allow users to do so via /etc/sysconfig/* -
common example with httod is to be able to set ORACLE_HOME).

So clearing the environment at the beginning of /etc/init.d/functions seems the
only route.  After some gooling, this funky hack should do it:

declare() {
  local var=${2%%=*}
  case "$var" in
  PATH|LANG|TERM) ;;
  *) unset -- "$var" ;;
  esac
}

eval "$(builtin declare -x)"
unset declare
Comment 13 Behdad Esfahbod 2005-10-03 07:41:50 EDT
Another way is to exec ourselves in a clean environment, something like:

if test x$MAGIC_CLEAN_ENV = x; then
  exec env -i MAGIC_CLEAN_ENV=y LANG=$LANG PATH=$PATH TERM=$TERM $0 "$@"
fi
unset MAGIC_CLEAN_ENV


But this way, there are a bunch of the init scripts that should be modified to
work, since they include their sysconfig config before including function.  With
your solution, only exported symbols are cleared, which means most probably no
modification is needed to any initscript at all.  Nice!
Comment 14 Bug Zapper 2008-04-03 11:27:34 EDT
Based on the date this bug was created, it appears to have been reported
against rawhide during the development of a Fedora release that is no
longer maintained. In order to refocus our efforts as a project we are
flagging all of the open bugs for releases which are no longer
maintained. If this bug remains in NEEDINFO thirty (30) days from now,
we will automatically close it.

If you can reproduce this bug in a maintained Fedora version (7, 8, or
rawhide), please change this bug to the respective version and change
the status to ASSIGNED. (If you're unable to change the bug's version
or status, add a comment to the bug and someone will change it for you.)

Thanks for your help, and we apologize again that we haven't handled
these issues to this point.

The process we're following is outlined here:
http://fedoraproject.org/wiki/BugZappers/F9CleanUp

We will be following the process here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping to ensure this
doesn't happen again.
Comment 15 Behdad Esfahbod 2008-04-15 16:25:17 EDT
Bug is valid as of F8.
Comment 16 Bug Zapper 2008-11-26 01:46:50 EST
This message is a reminder that Fedora 8 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 8.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '8'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 8's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 8 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 17 Bug Zapper 2009-11-18 02:48:54 EST
This message is a reminder that Fedora 10 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 10.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '10'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 10's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 10 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 18 Bug Zapper 2010-11-04 08:19:46 EDT
This message is a reminder that Fedora 12 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 12.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '12'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 12's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 12 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 19 Bill Nottingham 2010-11-30 21:56:22 EST
This is fixed in rawhide with systemd as the init daemon, and using it when init scripts are called.

Note You need to log in before you can comment on or make changes to this bug.