While running MailWatch (a webbased MailScanner/spamassassin front-end) I noticed that attempting to sa-learn something I got an error which said that mailwatch could not write to _my_ home directory. Since I use sudo -s while keeping my environment and then ran "/etc/init.d/apache restart" with root permissions but not as the user root apache was running with my environment. If I su - root and then restarted apache I got a simmilar error stating spamassassin could not write to /root/.spamassassin To prove my point I added "export HOME=/var/www" to the start() function, which indeed works around the problem. But I sense there is a deeper problem here which might even affect other init scripts. 1) Please make sure the apache initscript starts apache with the right environment. 2) Please audit other initscripts for the same behaviour. Reproducible: Always
Thank you for report, Han! This looks very similar to bug 347301. Could you tell us if solution suggested there works for you?
OK, I tried both variations, running as root, so the $HOME directory is /root # export HOME=/var/www # ${APACHE2} ${APACHE2_OPTS} -k start start-stop-daemon --start --pidfile "${PIDFILE}" ${APACHE2} -- ${APACHE2_OPTS} -k start SA Learn: error code 13 returned from sa-learn: bayes: expire_old_tokens: locker: safe_lock: cannot create lockfile /root/.spamassassin/bayes.mutex: Permission denied plugin: eval failed: bayes: (in learn) locker: safe_lock: cannot create lockfile /root/.spamassassin/bayes.mutex: Permission denied ERROR: the Bayes learn function returned an error, please re-run with -D for more information at /usr/bin/sa-learn line 493. Learned tokens from 0 message(s) (1 message(s) examined) And the other variation: export HOME=/var/www ${APACHE2} ${APACHE2_OPTS} -k start # start-stop-daemon --start --pidfile "${PIDFILE}" ${APACHE2} -- ${APACHE2_OPTS} -k start SA Learn: Learned tokens from 1 message(s) (1 message(s) examined)
Created attachment 285647 [details, diff] apach2.init.patch Oh, sorry Han for not being clear enough. What I had in mind: please try patch in attachment and tell me, if it fixes the issue for you?
Hello Peter, Although I didn't apply the patch what I tested boils down to exactly the same thing. Using "start-stop-daemon" does not set up the proper environment.
Heh, I see. @openrc, should this functionality work: # By default we filter the environment for our running scripts. To allow other # variables through, add them here. Use a * to allow all variables through. #rc_env_allow="VAR1 VAR2" ? Or could you comment on the issue?
In that case exporting HOME would have no effect and using the patch would make it even worse. The only proper way to give the proces the proper environment of the apache user would be something like "su - apache apache" Which would not permit it to open port 80/443 So you would have to do "su - apache -c 'sudo apache'" That seems beyond ugly. Lets see what those debian fellows do: From /etc/init.d/apache2 ----------------- if [ -z "$APACHE_ENVVARS" ] ; then APACHE_ENVVARS=$APACHE_CONFDIR/envvars fi export APACHE_CONFDIR APACHE_ENVVARS ENV="env -i LANG=C PATH=/usr/local/bin:/usr/bin:/bin" if [ "$APACHE_CONFDIR" != /etc/apache2 ] ; then ENV="$ENV APACHE_CONFDIR=$APACHE_CONFDIR" fi if [ "$APACHE_ENVVARS" != "$APACHE_CONFDIR/envvars" ] ; then ENV="$ENV APACHE_ENVVARS=$APACHE_ENVVARS" fi ----------------- A h. Lets look at /etc/apache2/envvars ------- # envvars - default environment variables for apache2ctl # this won't be correct after changing uid unset HOME # for supporting multiple apache2 instances if [ "${APACHE_CONFDIR##/etc/apache2-}" != "${APACHE_CONFDIR}" ] ; then SUFFIX="-${APACHE_CONFDIR##/etc/apache2-}" else SUFFIX= fi # Since there is no sane way to get the parsed apache2 config in scripts, some # settings are defined via environment variables and then used in apache2ctl, # /etc/init.d/apache2, /etc/logrotate.d/apache2, etc. export APACHE_RUN_USER=www-data export APACHE_RUN_GROUP=www-data export APACHE_PID_FILE=/var/run/apache2$SUFFIX.pid export APACHE_RUN_DIR=/var/run/apache2$SUFFIX export APACHE_LOCK_DIR=/var/lock/apache2$SUFFIX # Only /var/log/apache2 is handled by /etc/logrotate.d/apache2. export APACHE_LOG_DIR=/var/log/apache2$SUFFIX ## The locale used by some modules like mod_dav export LANG=C ## Uncomment the following line to use the system default locale instead: #. /etc/default/locale export LANG ## The command to get the status for 'apache2ctl status'. ## Some packages providing 'www-browser' need '--dump' instead of '-dump'. #export APACHE_LYNX='www-browser -dump' ------------ Makes sense, doesn't it?
s-s-d should not be filtering the env. openrc's runscript takes care of that. therefore, test Peter's proposed init.d patch
Mike, looks like filtering does not happens. I've tried with simple script: tablet init.d # cat /etc/init.d/foo #!/sbin/runscript start() { date >> /tmp/env env >> /tmp/env } and all user's environment is there, even in case I have uncommented: rc_env_allow="VAR1 VAR2" (although I guess filtering should happen even with commented rc_env_allow.) Han, by idea in Gentoo this should work even more elegant for all services we have: 1. in Gentoo environment should be filtered by default 2. to pass environment variable it should explicitly allowed either in global configuration file /etc/rc.conf or in "local" configuration file (/etc/conf.d/apache2). Thus by idea you should define variables in /etc/conf.d/apache2 (don't forget to export them), allow them with rc_env_allow="VAR1 VAR2" and then everything should work. And beside filtering everything works now. Please, test with my patch, please. Taking into account that this should work for all other services as well, I like Gentoo way more :)
seems to work for me. the whitelist doesnt delete all vars. you can see the list in src/rc/rc-misc.c:env_whitelist[]. like HOME. if you want apache to use the HOME from a user, then pass the -u option to apache so that it changes user and fix its HOME value.
(In reply to comment #9) > seems to work for me. the whitelist doesnt delete all vars. you can see the > list in src/rc/rc-misc.c:env_whitelist[]. like HOME. Well, it does not delete any variables here... GSETTINGS_BACKEND=gconf, XDG_DATA_DIRS and many other are still in /tmp/env file. I'm using openrc-0.9.3-r1.
are you sure those variables aren't being created fresh because of /etc/profile.env ?
Ah, it was not clear for me that profile variables are sourced in any case. So ... works for me too. As for initial bug report, Han, take a look at comment #8.
