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.benjamingodf...@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>
<j...@sunstarsys.com>
954.253.3732 <//954.253.3732>
