Bug 97604
Summary: | Clear environment for init scripts (was: Bad BASH_ENV causes Permission Denied in CGI scripts.) | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Behdad Esfahbod <behdad> |
Component: | initscripts | Assignee: | Bill Nottingham <notting> |
Status: | CLOSED RAWHIDE | QA Contact: | |
Severity: | medium | Docs Contact: | |
Priority: | high | ||
Version: | 12 | CC: | bugs+behnam, david, jorton, mitr, nalin, rvokal, triage |
Target Milestone: | --- | Keywords: | FutureFeature, Triaged |
Target Release: | --- | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | bzcl34nup | ||
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-12-01 02:56:22 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: | |||
Bug Depends On: | |||
Bug Blocks: | 150221 |
Description
Behdad Esfahbod
2003-06-18 10:09:43 UTC
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. |