Mailing List Archive

Apache2 chroot problem: towards a solution
Hi, I'm working on the problem of Apache2 ignoring requests to any command
in the chroot environment. I have seen complaints about this posted on a
couple of websites, and I have not seen any solution. I seem to have
narrowed the problem down to a relatively small section of the code, but I
have gotten ambiguous information on how to resolve the issue.

Initially, this problem comes across as a classic system
compatibility issue, but this it turns out is not the case. The solution
seems to be fairly easily solved, but either the Apache2 code would require
a slight modification, or a module would need to be written, if there isn't
a module that already solves the problem, that unlocks the Apache for Linux
users.


The errors follow the system information:

Distributor ID: Ubuntu
Description: Ubuntu 20.04.6 LTS
Release: 20.04
Codename: focal

Server version: Apache/2.4.41 (Ubuntu)


These are five typical errors:


systemctl status
System has not been booted with systemd as init system (PID 1). Can't
operate.
Failed to connect to bus: Host is down


sudo systemctl start apache2
Running in chroot, ignoring request: start


sudo apachectl start
Invoking 'systemctl start apache2'.
Use 'systemctl status apache2' for more info.
Running in chroot, ignoring request: start


sudo service apache2 restart
* Restarting Apache httpd web server apache2
Invoking
'systemctl start apache2'.
Use 'systemctl status apache2' for more info.
Running in chroot, ignoring request: start


sudo systemctl status apache2
Running in chroot, ignoring request: status



The irony is that the error message is stalling development on important
issues like the eventual migration to systemd while the text of the message
seems to point to the cause of the error as related to the systemd boot
process not being completed in the chroot. This isn't the case. The
errors are caused by the following code in Apache2:

if (ap_is_in_chroot()) {

ap_log_error(APLOG_MARK, APLOG_ERR, 0, APLOG_NOERRNO,

"Running in chroot, ignoring request: start");

return APR_SUCCESS;

}
This code begs the question, why is Apache2 even checking that the "ap" is
running in a chroot? It must be understood that using a chroot environment
is a useful security measure, and checking ap_is_in_chroot in this context
is limiting the usefulness of Apache for a number of users.

Further information varies, as I haven't been able to locate this segment
in the code. I have heard it is in the ap_run_mpm() function, and in the
server/mpm/common/main.c file

Other information, of which I am skeptical reports:

The ap_is_in_chroot() function is not a public function. It is an
internal function that is used by the Apache source code. As such, it is
not included in the public release of the Apache source code.

I am not sure if there could be a module that would solve this issue, and
I'm not sure if something like:

if [ -n "$AP_CHROOT_DIR" ]; then

unset AP_CHROOT_DIR

Fi
Would be enough to solve the issue?

Benjamin Godfrey
Re: Apache2 chroot problem: towards a solution [ In reply to ]
On 5/18/23 6:45 AM, Benjamin Godfrey wrote:
> Hi, I'm working on the problem of Apache2 ignoring requests to any command in the chroot environment.  I have seen complaints
> about this posted on a couple of websites, and I have not seen any solution.   I seem to have narrowed the problem down to a
> relatively small section of the code, but I have gotten ambiguous information on how to resolve the issue.  
>
> Initially, this problem comes across as a classic system compatibility issue, but this it turns out is not the case.   The
> solution seems to be fairly easily solved, but either the Apache2 code would require a slight modification, or a module would need
> to be written, if there isn't a module that already solves the problem, that unlocks the Apache for Linux users. 
>
>
> The errors follow the system information:  
>
> Distributor ID: Ubuntu
> Description:    Ubuntu 20.04.6 LTS
> Release:        20.04
> Codename:       focal
>
> Server version: Apache/2.4.41 (Ubuntu)
>
>
> These are five typical errors:
>
>
> systemctl status
> System has not been booted with systemd as init system (PID 1). Can't operate.
> Failed to connect to bus: Host is down
>
>
> sudo systemctl start apache2
> Running in chroot, ignoring request: start
>
>
> sudo apachectl start
> Invoking 'systemctl start apache2'.
> Use 'systemctl status apache2' for more info.
> Running in chroot, ignoring request: start
>
>
> sudo service apache2 restart
>  * Restarting Apache httpd web server apache2                                                                                    
>              Invoking 'systemctl start apache2'.
> Use 'systemctl status apache2' for more info.
> Running in chroot, ignoring request: start
>
>
> sudo systemctl status apache2
> Running in chroot, ignoring request: status
>
>
>
> The irony is that the error message is stalling development on important issues like the eventual migration to systemd while the
> text of the message seems to point to the cause of the error as related to the systemd  boot process not being completed in the
> chroot.  This isn't the case.  The  errors are caused by the following code in Apache2:
>
> if (ap_is_in_chroot()) {
>
>     ap_log_error(APLOG_MARK, APLOG_ERR, 0, APLOG_NOERRNO,
>
>                  "Running in chroot, ignoring request: start");
>
>     return APR_SUCCESS;
>
> }
>
> This code begs the question, why is Apache2 even checking that the "ap" is running in a chroot?  It must be understood that using
> a chroot environment is a useful security measure, and checking ap_is_in_chroot in this context is limiting the usefulness of
> Apache for a number of users.  
>
> Further information varies, as I haven't been able to locate this segment in the code.  I have heard it is in the ap_run_mpm()
> function,  and in the server/mpm/common/main.cfile
>  
> Other information, of which I am skeptical reports:
>
>    The ap_is_in_chroot()function is not a public function. It is an internal function that is used by the Apache source code. As
> such, it is not included in the public release of the Apache source code.

This code is not found in our code base. It seems to origin from an Ubuntu created patch. Hence you need to discuss about it with
the Ubuntu people.

Regards

Rüdiger
Re: Apache2 chroot problem: towards a solution [ In reply to ]
Awesome that Ubuntu package managers are moonlighting as open source
developer perfectionists instead of working with upstream projects on
issues.

On Thu, May 18, 2023 at 12:47 AM Benjamin Godfrey <
mr.benjamingodfrey@gmail.com> wrote:

> Hi, I'm working on the problem of Apache2 ignoring requests to any command
> in the chroot environment. I have seen complaints about this posted on a
> couple of websites, and I have not seen any solution. I seem to have
> narrowed the problem down to a relatively small section of the code, but I
> have gotten ambiguous information on how to resolve the issue.
>
> Initially, this problem comes across as a classic system
> compatibility issue, but this it turns out is not the case. The solution
> seems to be fairly easily solved, but either the Apache2 code would require
> a slight modification, or a module would need to be written, if there isn't
> a module that already solves the problem, that unlocks the Apache for Linux
> users.
>
>
> The errors follow the system information:
>
> Distributor ID: Ubuntu
> Description: Ubuntu 20.04.6 LTS
> Release: 20.04
> Codename: focal
>
> Server version: Apache/2.4.41 (Ubuntu)
>
>
> These are five typical errors:
>
>
> systemctl status
> System has not been booted with systemd as init system (PID 1). Can't
> operate.
> Failed to connect to bus: Host is down
>
>
> sudo systemctl start apache2
> Running in chroot, ignoring request: start
>
>
> sudo apachectl start
> Invoking 'systemctl start apache2'.
> Use 'systemctl status apache2' for more info.
> Running in chroot, ignoring request: start
>
>
> sudo service apache2 restart
> * Restarting Apache httpd web server apache2
>
> Invoking 'systemctl start apache2'.
> Use 'systemctl status apache2' for more info.
> Running in chroot, ignoring request: start
>
>
> sudo systemctl status apache2
> Running in chroot, ignoring request: status
>
>
>
> The irony is that the error message is stalling development on important
> issues like the eventual migration to systemd while the text of the message
> seems to point to the cause of the error as related to the systemd boot
> process not being completed in the chroot. This isn't the case. The
> errors are caused by the following code in Apache2:
>
> if (ap_is_in_chroot()) {
>
> ap_log_error(APLOG_MARK, APLOG_ERR, 0, APLOG_NOERRNO,
>
> "Running in chroot, ignoring request: start");
>
> return APR_SUCCESS;
>
> }
> This code begs the question, why is Apache2 even checking that the "ap" is
> running in a chroot? It must be understood that using a chroot environment
> is a useful security measure, and checking ap_is_in_chroot in this context
> is limiting the usefulness of Apache for a number of users.
>
> Further information varies, as I haven't been able to locate this segment
> in the code. I have heard it is in the ap_run_mpm() function, and in the
> server/mpm/common/main.c file
>
> Other information, of which I am skeptical reports:
>
> The ap_is_in_chroot() function is not a public function. It is an
> internal function that is used by the Apache source code. As such, it is
> not included in the public release of the Apache source code.
>
> I am not sure if there could be a module that would solve this issue, and
> I'm not sure if something like:
>
> if [ -n "$AP_CHROOT_DIR" ]; then
>
> unset AP_CHROOT_DIR
>
> Fi
> Would be enough to solve the issue?
>
> Benjamin Godfrey
>
>
> --
Joe Schaefer, Ph.D.
<https://sunstarsys.com/orion/features>
Orion - The Enterprise Jamstack Wiki <https://sunstarsys.com/orion/features>
<joe@sunstarsys.com>
954.253.3732 <//954.253.3732>
Apache2 chroot problem: towards a solution [ In reply to ]
Dear Apache2 team,

Thank you for your help in trying to resolve the issue I am having with the
Apache server inside of a chroot environment on a Chromebook. I thought I
had narrowed the problem down to a piece of code in Apache2 that checks if
the server is running in a chroot. This code causes Apache2 to ignore any
requests to start, stop, or restart the server.

I have since my previous request learned that the reason that there is a
check for the chroot is so that Apache2 doesn’t escape from the chroot.
It seems to me to be an error in logic to ignore requests when the
conditions indicate that a process should proceed with what it is supposed
to do.

I have already contacted other developers and I share your frustration they
have have not worked with the Apache HTTPD project to resolve this issue.

I am writing to you today to ask for your help in resolving this issue. I
understand that the Ubuntu package maintainers are not responsible for the
Apache HTTPD project, but I believe that you may be able to connect me to a
developer who can help me resolve this issue.

I would be grateful if you could provide me with the contact information
for a developer who can help me with this issue or other assistance such as
directing me to a module that might help, or direct me to some
documentation that would help me solve this technical issue.

Yours truly,

Benjamin Godfrey
Re: Apache2 chroot problem: towards a solution [ In reply to ]
> I am writing to you today to ask for your help in resolving this issue.

I don't think this issue required another thread. Have you tried
https://httpd.apache.org/docs/2.4/mod/mod_unixd.html#chrootdir ?