Bug 364453 – www-servers/apache - /etc/init.d/apache2 does not reset HOME to apache user

• Product: Gentoo Linux
• Status: RESOLVED WORKSFORME

[Description Han Boetes 2011-04-22 07:15:37 UTC]

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

[Comment 1 Peter Volkov (RETIRED) 2011-09-01 17:34:14 UTC]

Thank you for report, Han! This looks very similar to bug 347301. Could you tell us if solution suggested there works for you?

[Comment 2 Han Boetes 2011-09-05 09:45:21 UTC]

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)

[Comment 3 Peter Volkov (RETIRED) 2011-09-05 15:07:20 UTC]

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?

[Comment 4 Han Boetes 2011-09-06 08:10:31 UTC]

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.

[Comment 5 Peter Volkov (RETIRED) 2011-09-06 10:47:21 UTC]

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?

[Comment 6 Han Boetes 2011-09-06 13:03:20 UTC]

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?

[Comment 7 SpanKY 2011-09-15 04:16:59 UTC]

s-s-d should not be filtering the env.  openrc's runscript takes care of that.

therefore, test Peter's proposed init.d patch

[Comment 8 Peter Volkov (RETIRED) 2011-09-15 06:43:30 UTC]

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 :)

[Comment 9 SpanKY 2011-09-17 04:20:02 UTC]

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.

[Comment 10 Peter Volkov (RETIRED) 2011-09-19 11:21:40 UTC]

(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.

[Comment 11 SpanKY 2011-09-19 14:31:00 UTC]

are you sure those variables aren't being created fresh because of /etc/profile.env ?

[Comment 12 Peter Volkov (RETIRED) 2011-10-02 18:26:20 UTC]

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.