+++ This bug was initially created as a clone of Bug #203010 +++ Description of problem: When running the daemon() function from an initscript and using the "--user" option, daemon will run "/sbin/runuser" to execute. This command clears the environment by default unless the -m or -p arguments are given. This can create a problem because some initscripts set environment variables for their programs' use. Version-Release number of selected component (if applicable): FC5+ How reproducible: Always. Steps to Reproduce: 1. Export a variable in an initscript which sources /etc/init.d/functions 2. call a program using the "daemon --user BLAH program" syntax Actual results: The variable you exported will not be present in the program's environment. Expected results: That the variable would be available, yo, regardless of the fact that we're switching users. --- Additional comment from cleaver.edu on 2006-08-17 15:26:02 EDT --- *** Bug 203011 has been marked as a duplicate of this bug. *** --- Additional comment from cleaver.edu on 2006-08-17 15:38:12 EDT --- This is identical to Bug 123032, which was closed. --- Additional comment from jonstanley on 2008-04-23 16:28:50 EDT --- Adding FutureFeature keyword to RFE's. --- Additional comment from cleaver.edu on 2009-03-24 18:05:56 EDT --- Any thoughts on this bug/feature? Given the lack of documentation, it seems like a simple declaration that daemon() no longer clears the environment would be sufficient; then add '-m' to the relevant line. if [ -z "$user" ]; then $nice /bin/bash -c "$corelimit >/dev/null 2>&1 ; $*" else $nice runuser -s /bin/bash - $user -c "$corelimit >/dev/null 2>&1 ; $*" fi
This bug effects MRG qpidd for those customers using kerberos. The KRB5_KTNAME environment variable is used to tell the sasl component of qpidd where the kerb keytab file can be found. Setting the env var in the /etc/sysconfig/qpidd file will not work, since daemon() clears the environment before starting qpidd. A work around is to set permissions on the default keytab file /etc/krb5.keytab so qpidd can read it - which is a security issue. It would be great if the daemon() function in /etc/init.d/functions would allow a parameter that would cause runuser to preserve the environment. thanks, -K
Fixed in upstream commit http://git.fedorahosted.org/git/?p=initscripts.git;a=commitdiff;h=89183909b2965e6bc2991b2512161414d2028be8
Note: this commit does not actually do what is required. http://git.fedorahosted.org/git/?p=initscripts.git;a=commitdiff;h=a3d105dfafd6198c1457e87550e1b46945dd882d is more correct. Currently being tested in Fedora for side effects.
See https://bugzilla.redhat.com/show_bug.cgi?id=564105#c19 - you may need to export your variables?
An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on therefore solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHBA-2011-0075.html
*** Bug 782139 has been marked as a duplicate of this bug. ***
Please re-open this bug. It is not fixed in RHEL 5.7 nor 6.2. Neither the -m nor -p options for run user are anywhere in the daemon() function. Regression?
The fix was to drop the '-' from the line, which was making bash a login shell, which was what was the actual difference causing the environment shift (in testing). Is the fixed version not working for you?
No, it doesn't work for me. I'm still ending up with a "fresh" environment with the variables I exported (actually exported, not just set) in my script disappearing. If I run "env" right before calling daemon() I can see the variables with the values I expect. I assumed that runuser was clearing out the env before executing the command (purely based on the documentation of the -m/-p flags). If I add -m/-p to runuser it works fine. In this particular instance, I'm using daemon() to start up httpd as a non-root user. What info can I provide to help?
Will comment in bug 782139.