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.
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.
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.
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?
It would better go into daemon(), to do the work for manual starts by /etc/init.d/* [re]start.
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.
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.
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.
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.
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
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?
I seem to have that problem with shell scripts started by xinetd in 2.1WS and find it very annoying.
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
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!
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.
Bug is valid as of F8.
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
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
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
This is fixed in rawhide with systemd as the init daemon, and using it when init scripts are called.