Bug 292632 – openrc breaks --chroot option of start-stop-daemon

• Product: Gentoo Linux
• Status: RESOLVED DUPLICATE

[Description Marshall McMullen 2009-11-10 03:51:17 UTC]

Last night upgrade to baselayout-2 and openrc, and a custom init script I use with the --chroot option no longer works even though it was fine under baselayout-1. Removing the --chroot option allows the script to work again albeit without the desired functionality. I search for related bugs and saw Bug 219184. It's not a dup though as all my other init scripts with pam use flag work fine. The only one that fails is one using --chroot flag. I'll attach the offending init script.

Reproducible: Always

Steps to Reproduce:
1.try running attached rtorrent init script with openrc-0.4.2 installed

Actual Results:  
* Starting rtorrent: chroot=/.chroot/apache, user=p2p, socket=/tmp/rtorrent.dtach...
* start-stop-daemon: pam error: Module is unknown
* start-stop-daemon: failed to start `/usr/bin/dtach'                                                                                                         [ !! ]
* ERROR: rtorrent failed to start


Expected Results:  
rtorrent init script should start successfully in the chroot.

[Comment 1 Marshall McMullen 2009-11-10 03:52:05 UTC]

Created attachment 209804 [details]
failing rtorrent init script

[Comment 2 Marshall McMullen 2009-11-10 03:52:35 UTC]

Created attachment 209806 [details]
/etc/conf.d/rtorrent file

[Comment 3 Marshall McMullen 2009-11-10 03:55:32 UTC]

Correction, I have this version of openrc installed: 0.4.3-r4

[Comment 4 Marshall McMullen 2009-11-10 04:03:46 UTC]

I also just tried upgrading to sys-apps/openrc-0.5.2-r2 and the problem still persists.

[Comment 5 Marshall McMullen 2009-11-10 04:05:24 UTC]

Following the suggestion in Bug 219184 I re-emerged openrc with USE=-pam and the problem went away.

[Comment 6 Markos Chandras (RETIRED) 2009-11-10 04:13:48 UTC]

(In reply to comment #5)
> Following the suggestion in Bug 219184 I re-emerged openrc with USE=-pam and
> the problem went away.
> 

Good. Sounds like a duplicate of that bug

*** This bug has been marked as a duplicate of bug 219184 ***

[Comment 7 Marshall McMullen 2009-11-10 04:17:11 UTC]

I'm confused why Bug 219184 is marked as resolved when there's no resolution in the bug. In this particular case, turning off the pam use flag seems like a workaround but not a resolution. 

[Comment 8 Laszlo Valko 2011-05-11 01:22:54 UTC]

Guys, I don't think this is a duplicate of 219184...
Well, at least not in some sense.

Both bugs are about start-stop-daemon not being able to use pam.

This bug is about why start-stop-daemon is not able to use pam if using --chroot, when it's perfectly happy if not using --chroot.

And I know that by now.

It's because start-stop-daemon is doing chroot() first, and then later expects to be able to use libpam. And _that_ is a bug, unless someone has reasons why that would be a sane thing to do.

To use libpam, there are multiple conditions to satisfy, and handcrafted chroot jails sometimes do not satisfy those conditions - it is perfectly reasonable not to put a 'nobody' user into my chroot jail, if my service does not need it. And it is perfectly reasonable not to put pam config & .so files in there, if the service does not use pam...

[Comment 9 Tilman Giese 2011-05-12 09:47:44 UTC]

I would go even one step further. This is a security leak. If the system's PAM configuration does not allow you to use start-stop-daemon, just create a copy of the PAM configuration, change it accordingly and use start-stop-daemon with the --chroot option which effectively allows you to bypass the system's configuration.

[Comment 10 rpansky 2011-05-18 15:00:38 UTC]

I confirm the issue w.r.t. the stable openrc version:
sys-apps/openrc-0.8.2-r1  USE="ncurses pam unicode -debug (-selinux)"

The following code in a custom init script:
start-stop-daemon --start \
        --env HOME=${MLDONKEY_DIR} \
        --chroot ${CHROOT} \
        --pidfile ${MLDONKEY_PID}  --make-pidfile \
        --chuid ${MLDONKEY_USER} \
        --nice ${NICE} \
        --exec ${MLDONKEY_BINARY}

results in the message:
start-stop-daemon: pam error: Critical error - immediate abort

Please consider reopening this bug since there are no obvious reasons to identify it with https://bugs.gentoo.org/show_bug.cgi?id=219184. Moreover, unlike the latter, this bug has been confirmed for recent openrc versions.

[Comment 11 Anton Luka Šijanec 2022-04-18 11:35:00 UTC]

More than 10 years later and I stumbled upon this bug and opened a PR over at upstream OpenRC's repository where start-stop-daemon is located. As Laszlo in comment 8 mentioned, chroot(2) is called before pam_start(3), so pam_start does not get access to pam configuration files.

PR is on github.com/OpenRC/openrc/pull/517/.

It's possible that that's desired, but I doubt it.

Another issue I found while writing my init file (also written in PR discussion): --std{err,out}{-logger,} option arguments start the logger process or open the logger file after the call to chroot(2). This, unlike the above issue, is documented in the start-stop-daemon(8) manpage.

I also made a patch that provides four additional options, --std{err,out}{-logger,}-before-chroot, that start the logger or open the logfile before chrooting.

I tested options --stderr-before-chroot and --std{err,out}-logger-before-chroot they worked. I do not know how to write manpages, so I can't just commit this other change to the upstream PR before adding options to the manpage. Can someone help me?

My patched version is on 1507103400/krneki/start-stop-daemon.c

I omitted the protocol from URLs, because my bugzilla account is younger than 24 hours, which prohibits me from sending URLs.