Chroot fails with "Cannot chroot when not started as root" error

Bug #1251939 reported by Arul on 2013-11-17
12
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Apache2 Web Server
Fix Released
High
apache2 (Ubuntu)
Medium
Unassigned
Saucy
Medium
Unassigned

Bug Description

[Impact]

The Apache ChrootDir directive doesn't work, causing Apache to fail if you try to use it. This means that it is not possible to run Apache in a chroot, which is a regression from 13.04.

[Development Fix]

Adjust build system to not use things inside .pc/. This also requires the regeneration of debian/patches/itk-rerun-configure.patch.

[Stable Fix]

Same as development fix.

[Test Case]

In included dep8 test. Install dpkg-dev and wget, then run "sh debian/tests/chroot". This requires root, and will clobber your Apache installation, so do this only on a fresh install that you can throw away afterwards.

[Regression Potential]

Having to adjust the build system is not ideal, and could impact anything. But what was being done before is obviously flawed, and could introduce other problems not yet reported.

On balance, I think it is worth the SRU, since the unknowns also include other bugs that we don't know about.

It might be worth mandating additional verification here, though, or a longer than normal aging period.

I will leave the SRU team to decide.

[Original Description]

I have set my chroot directory as shown below.

ChrootDir /var/www

When started with the above chroot setting, apache2 exits with the following error

[Sat Nov 16 13:52:40.621872 2013] [unixd:alert] [pid 3747] (34)Numerical result out of range: AH02158: Cannot chroot when not started as root

NOTE: apache2 is started as 'root' user. This was reported as a bug in apache.org earlier (link below) where it was confirmed this is fixed in a trunk.
https://issues.apache.org/bugzilla/show_bug.cgi?id=55787

Details of my Ubuntu server:
-------------------------------------------------
root@gorilla:~# cat /etc/lsb-release
DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=13.10
DISTRIB_CODENAME=saucy
DISTRIB_DESCRIPTION="Ubuntu 13.10"

root@gorilla:~# apache2ctl -v
Server version: Apache/2.4.6 (Ubuntu)
Server built: Aug 9 2013 14:31:04

root@gorilla:~# apache2ctl -l -M
Compiled in modules:
  core.c
  mod_so.c
  mod_watchdog.c
  http_core.c
  mod_log_config.c
  mod_logio.c
  mod_version.c
  mod_unixd.c
  mod_unixd.c

I have set my chroot directory as shown below.

ChrootDir /var/www

When started with the above chroot setting, apache2 exits with the following error

[Sat Nov 16 10:20:54.241556 2013] [unixd:alert] [pid 12802] (2)No such file or directory: AH02158: Cannot chroot when not started as root

NOTE: apache2 is started as 'root' user. It looks like the call to check geteuid() is made after apache2 lowers its privilege to APACHE_RUN_USER?

I am not sure this is a bug or configuration issue. This directory (/var/www) mentioned above was setup with everything needed for chroot'ed environment with libapache2-mod-chroot and was working fine for many years running under apache 2.2. Recently, I upgraded to 2.4.6 and wanted to switch to apache2's native Chroot since mod_chroot is no longer maintained and I am now stuck with the above error.

Dropping userid happens later in the same function. Also, works for me.

Can you demonstrate with a minimal configuration and include it w/ an strace -f of startup?

Created attachment 31048
strace output

Here you go...

root@gorilla:/etc/apache2# rm /var/log/apache2/error.log
root@gorilla:/etc/apache2# apachectl start >/tmp/apache2_strace.log 2>&1

I am attaching apache.conf and apache2.strace.log

Created attachment 31049
error log

Created attachment 31050
minimal apache.conf

Pretty weird, the trace shows geteuid(), chdir(), chroot() which are all after the message you say was issued (assuming it hasn't changed recently) but those all follow the error.

It's almost like you have a 2nd copy of the mod_unixd code loaded.

can you add apachectl -l and -M output w/ the same conf from the strace?

Very interesting.... I do see it loaded twice!, how do I get rid of one?

root@gorilla:/etc/apache2# apachectl -l -M
Compiled in modules:
  core.c
  mod_so.c
  mod_watchdog.c
  http_core.c
  mod_log_config.c
  mod_logio.c
  mod_version.c
  mod_unixd.c
  mod_unixd.c
root@gorilla:/etc/apache2#

(In reply to Arul from comment #6)
> Very interesting.... I do see it loaded twice!, how do I get rid of one?
>
> root@gorilla:/etc/apache2# apachectl -l -M
> mod_unixd.c
> mod_unixd.c
> root@gorilla:/etc/apache2#

That is an impressive bug. Can you open a bug against ubuntu/debian/wherever the build comes from?

Trunk fix: r1542615 .

This will fixed in Debian in the next upload. If you use an already released version of Ubuntu that includes 2.4, you need to file a bug report with Ubuntu.

Yes, I am using the latest Ubuntu 13.10 that includes the 2.4.6 version.

root@gorilla:~# apache2ctl -v
Server version: Apache/2.4.6 (Ubuntu)
Server built: Aug 9 2013 14:31:04
root@gorilla:~# cat /etc/lsb-release
DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=13.10
DISTRIB_CODENAME=saucy
DISTRIB_DESCRIPTION="Ubuntu 13.10"

I will file a bug report w/ Ubuntu referencing this.

Thank you for your help.

(In reply to Arul Selvan from comment #9)
> Yes, I am using the latest Ubuntu 13.10 that includes the 2.4.6 version.
>
> root@gorilla:~# apache2ctl -v
> Server version: Apache/2.4.6 (Ubuntu)
> Server built: Aug 9 2013 14:31:04
> root@gorilla:~# cat /etc/lsb-release
> DISTRIB_ID=Ubuntu
> DISTRIB_RELEASE=13.10
> DISTRIB_CODENAME=saucy
> DISTRIB_DESCRIPTION="Ubuntu 13.10"
>
> I will file a bug report w/ Ubuntu referencing this.
>
> Thank you for your help.

Bug report filed in Ubuntu:
https://bugs.launchpad.net/ubuntu/+source/apache2/+bug/1251939

Robie Basak (racb) wrote :

Thank you for taking the time to report this bug and helping to make Ubuntu better.

Looks like we need to cherry-pick this upstream fix if we do not merge it in first.

Changed in apache2 (Ubuntu):
status: New → Triaged
Robie Basak (racb) wrote :

Since ChrootDir is not a default option, I think Medium priority is appropriate given the criteria listed at https://wiki.ubuntu.com/Bugs/Importance. That's not to say we shouldn't fix it, and an SRU to Saucy isn't out of the question, either.

Changed in apache2 (Ubuntu):
importance: Undecided → Critical
importance: Critical → Medium
Arul (aselvan) wrote :

Thank you for reviewing this bug report and assigning the severity. While I agree with you on the assigned severity of "Medium", I'd like to point out that though ChrootDir is not a default option, it relates to the security of apache server. I am not sure how many users simply use the server w/ default options, but I would guess many will do server hardening starting with chrooting. Would really appreciate if this fix is included soon.

Stefan Fritsch (sf-sfritsch) wrote :

If you fix that, you also need to regenerate debian/patches/itk-rerun-configure.patch after the upstream patch has been applied . I have done that in the attached patch. I would recommend that you do that for saucy.

This will also be fixed in 2.4.6-4, which will be uploaded to Debian soon. Therefore for trusty, there is probably no need for further action.

The attachment "patch against 2.4.6-2" seems to be a patch. If it isn't, please remove the "patch" flag from the attachment, remove the "patch" tag, and if you are a member of the ~ubuntu-reviewers, unsubscribe the team.

[This is an automated message performed by a Launchpad user owned by ~brian-murray, for any issues please contact him.]

tags: added: patch
Arul (aselvan) wrote :

Any update on when can we get a fix for this?

Robie Basak (racb) wrote :

As 2.4.6-4 hasn't been uploaded to Debian yet, and fixing Trusty blocks fixing Saucy, I've verified the problem with a dep8 test, verified Stefan's patch with it and uploaded the fix to Trusty. Thanks!

Changed in apache2 (Ubuntu):
status: Triaged → Fix Committed
Changed in apache2 (Ubuntu Saucy):
status: New → Triaged
importance: Undecided → Medium
Robie Basak (racb) on 2013-11-28
description: updated
description: updated
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package apache2 - 2.4.6-2ubuntu4

---------------
apache2 (2.4.6-2ubuntu4) trusty; urgency=low

  * d/p/ignore-quilt-dir, d/p/itk-rerun-configure.patch: adjust build system so
    that it does not use files find inside the .pc directory. This stops a
    double module load causing later havoc, including "ChrootDir" directive
    failure (LP: #1251939). Thanks to Stefan Fritsch.
  * d/tests/chroot: dep8 test for ChrootDir case.
 -- Robie Basak <email address hidden> Thu, 28 Nov 2013 16:21:51 +0000

Changed in apache2 (Ubuntu):
status: Fix Committed → Fix Released

Hello Arul, or anyone else affected,

Accepted apache2 into saucy-proposed. The package will build now and be available at http://launchpad.net/ubuntu/+source/apache2/2.4.6-2ubuntu2.1 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, and change the tag from verification-needed to verification-done. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed. In either case, details of your testing will help us make a better decision.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

Changed in apache2 (Ubuntu Saucy):
status: Triaged → Fix Committed
tags: added: verification-needed
Arul (aselvan) wrote :

I can confirm that Chroot is working in the proposed (2.4.6-2ubuntu2.1 )
Thank you for the fix.
-Arul

Miklos Juhasz (mjuhasz) on 2013-12-07
tags: added: verification-done
removed: verification-needed

The verification of the Stable Release Update for apache2 has completed successfully and the package has now been released to -updates. Subsequently, the Ubuntu Stable Release Updates Team is being unsubscribed and will not receive messages about this bug report. In the event that you encounter a regression using the package from -updates please report a new bug using ubuntu-bug and tag the bug report regression-update so we can easily find any regresssions.

Launchpad Janitor (janitor) wrote :

This bug was fixed in the package apache2 - 2.4.6-2ubuntu2.1

---------------
apache2 (2.4.6-2ubuntu2.1) saucy; urgency=low

  * d/p/ignore-quilt-dir, d/p/itk-rerun-configure.patch: adjust build system so
    that it does not use files find inside the .pc directory. This stops a
    double module load causing later havoc, including "ChrootDir" directive
    failure (LP: #1251939). Thanks to Stefan Fritsch.
  * d/tests/chroot: dep8 test for ChrootDir case.
 -- Robie Basak <email address hidden> Thu, 28 Nov 2013 17:45:57 +0000

Changed in apache2 (Ubuntu Saucy):
status: Fix Committed → Fix Released

Hi Stefan,

Remember this bug?
https://issues.apache.org/bugzilla/show_bug.cgi?id=55787
https://bugs.launchpad.net/ubuntu/+source/apache2/+bug/1251939
http://svn.apache.org/viewvc/httpd/httpd/trunk/build/config-stubs?view=log&pathrev=1542615

I really appreciated your fix for that.

I'm merging apache2 2.4.7-1 from Debian into Ubuntu, but I can't find
the fix in Debian for this issue. The upstream fix doesn't seem to be
present, and I tried dropping a config*.m4 file into .pc/ and the
"configfiles=" line picks it up.

So is Debian 2.4.7-1 still affected by this issue, or has there been
some other fix of which I'm not aware? I'm not sure whether this is a
bug in Debian, or if I'm missing something.

I'd appreciate your thoughts.

Thanks,

Robie

Stefan Fritsch (sf-sfritsch) wrote :

Hi Robie,

Am Freitag, 3. Januar 2014, 16:53:26 schrieb Robie Basak:
> I'm merging apache2 2.4.7-1 from Debian into Ubuntu, but I can't
> find the fix in Debian for this issue. The upstream fix doesn't
> seem to be present, and I tried dropping a config*.m4 file into
> .pc/ and the "configfiles=" line picks it up.
>
> So is Debian 2.4.7-1 still affected by this issue, or has there been
> some other fix of which I'm not aware? I'm not sure whether this is
> a bug in Debian, or if I'm missing something.

You are right, the real fix is not included. We "fixed" the issue by
removing the patches that touch *.m4 files. Therefore, no *.m4 file
will be created in the .pc directory.

This reminds me that I need to propose the upstream patch for backport
to 2.4.8. Maybe we should put the fix into the debian package for
2.4.7-2, too, but there are usually few reasons to patch the m4 files,
now that we have moved mpm-itk to its own source package.

Cheers,
Stefan

Robie Basak (racb) wrote :

Hi Stefan,

Thank you for explaining this to me.

On Sat, Jan 04, 2014 at 07:11:58PM +0100, Stefan Fritsch wrote:
> You are right, the real fix is not included. We "fixed" the issue by
> removing the patches that touch *.m4 files. Therefore, no *.m4 file
> will be created in the .pc directory.
>
> This reminds me that I need to propose the upstream patch for backport
> to 2.4.8. Maybe we should put the fix into the debian package for
> 2.4.7-2, too, but there are usually few reasons to patch the m4 files,
> now that we have moved mpm-itk to its own source package.

I'm wondering if there's more of a potential issue in Ubuntu than in
Debian here. Our next release will be supported for five years, so I
expect that we'll backport a number of as-yet-unknown bug fixes. As
we're team based, it could be anybody doing this, and they may be
unaware of this issue.

So I think I'd prefer to carry the backported fix for this, just so
there isn't a mine for a future developer to step on.

We prefer to keep our delta against Debian small, so that's a vote from
me to have the fix in 2.4.7-2, please. That's assuming that we just need
the ignore-quilt-dir patch, or are there any complications with
build system regeneration or anything like that?

I'll also look to see if I can write a dep8 test that just checks for
duplicate module loads.

Thanks,

Robie

Stefan Fritsch (sf-sfritsch) wrote :

Hi Robie,

Am Montag, 6. Januar 2014, 13:01:06 schrieb Robie Basak:
> I'm wondering if there's more of a potential issue in Ubuntu than in
> Debian here. Our next release will be supported for five years, so
> I expect that we'll backport a number of as-yet-unknown bug fixes.
> As we're team based, it could be anybody doing this, and they may
> be unaware of this issue.
>
> So I think I'd prefer to carry the backported fix for this, just so
> there isn't a mine for a future developer to step on.
>
> We prefer to keep our delta against Debian small, so that's a vote
> from me to have the fix in 2.4.7-2, please. That's assuming that we
> just need the ignore-quilt-dir patch, or are there any
> complications with build system regeneration or anything like that?

The code is only executed when running buildconf to re-create
configure. This is not normally done during package build. Therefore
the patch to build/config-stubs is sufficient to avoid the problem in
the future if/when someone needs to re-run buildconf again. I have
committed the patch to be included in 2.4.7-2.

Cheers,
Stefan

Robie Basak (racb) wrote :

On Sun, Jan 12, 2014 at 11:02:32PM +0100, Stefan Fritsch wrote:
> The code is only executed when running buildconf to re-create
> configure. This is not normally done during package build. Therefore
> the patch to build/config-stubs is sufficient to avoid the problem in
> the future if/when someone needs to re-run buildconf again.

Handy to know, thanks.

> I have
> committed the patch to be included in 2.4.7-2.

Perfect. Thank you very much for your help!

Robie

This has been backported in 2.4.x in r1555792 and is part of 2.4.7.

The ubuntu launchpad issue in comment #10 is also marked as "Fix Released"

Changed in apache2:
importance: Unknown → High
status: Unknown → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.