Bug 784921
| Summary: | Support for chrooted services is not good | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Adam Tkac <atkac> |
| Component: | systemd | Assignee: | systemd-maint |
| Status: | CLOSED ERRATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | unspecified | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 17 | CC: | johannbg, johannbg, lpoetter, metherid, mschmidt, notting, ovasik, plautrba, systemd-maint |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | systemd-37-19.fc16 | Doc Type: | Bug Fix |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2012-03-21 19:10:09 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
|
Description
Adam Tkac
2012-01-26 16:27:27 UTC
(In reply to comment #0) > ExecStartPre=/usr/libexec/setup-named-chroot.sh $ROOTDIR on BTW, I cannot find setup-named-chroot.sh in any of the packages. > Jan 26 16:52:29 rawhide named[2852]: Failed at step FDS spawning > /usr/sbin/named: No such file or directory In this message it's not /usr/sbin/named that the "No such file or directory" is about. "step FDS" is not too obvious at first sight, but it means it failed when attempting to close all file descriptors. close_all_fds() is called after chroot() and it wants to iterate over /proc/self/fd. Does it help if you have /proc mounted in the chroot? Maybe we can stop requiring that by just changing the order in exec_spawn() - first close all fds, then chroot. (In reply to comment #0) > I though about possible solutions for this and the only one is to `mount > --bind` the executable itself with all it's dynamic dependencies into chroot. I believe that's what this sentence in the manpage is saying: RootDirectory= [...] it must be ensured that the process and all its auxiliary files are available in the chroot() jail. The question is whether systemd should provide a helper utility to be called in ExecStartPre to have the executable and its libraries bind-mounted into the chroot automatically. Does there already exists a utility that would do something like that?: bind-mount-executable-and-its-libraries /path/to/elf/binary /path/to/chroot Here's a more general thought about chrooting services. Either the daemon itself does the chroot(), or you let systemd do it. There's a definitely a trade-off: Pros(+) and cons(-) for letting systemd do it (using RootDirectory=): + it can work for programs that do not know how to chroot themselves + the program does not even get a chance to screw it up - the binary and the libraries have to be present in the chroot directory It's conceivable that in the bind case the pros can be so insignificant and the con so annoying that you may decide to depend on bind to chroot itself. I think the rule of thumb simply should be if the daemon does the chroot() himself he should be the one to do it not systemd... (In reply to comment #2) > (In reply to comment #0) > > I though about possible solutions for this and the only one is to `mount > > --bind` the executable itself with all it's dynamic dependencies into chroot. > > I believe that's what this sentence in the manpage is saying: > > RootDirectory= > [...] it must be ensured that the process and all its auxiliary files are > available in the chroot() jail. > > The question is whether systemd should provide a helper utility to be called in > ExecStartPre to have the executable and its libraries bind-mounted into the > chroot automatically. Does there already exists a utility that would do > something like that?: > bind-mount-executable-and-its-libraries /path/to/elf/binary /path/to/chroot Question if that should not be added to mount units? (In reply to comment #3) > Here's a more general thought about chrooting services. > > Either the daemon itself does the chroot(), or you let systemd do it. There's a > definitely a trade-off: > Pros(+) and cons(-) for letting systemd do it (using RootDirectory=): > + it can work for programs that do not know how to chroot themselves > + the program does not even get a chance to screw it up > - the binary and the libraries have to be present in the chroot directory > > It's conceivable that in the bind case the pros can be so insignificant and the > con so annoying that you may decide to depend on bind to chroot itself. I think the rule of thumb simply should be if the daemon does the chroot() himself he should be the one to do it not the systemd unit... We probably should fix systemd to not require /proc to close all fds. We should just fall back to the classic loop until the rlimit in this case. Fixed in git which I well upload to F17, soon. systemd-44-1.fc17 has been submitted as an update for Fedora 17. https://admin.fedoraproject.org/updates/systemd-44-1.fc17 Package systemd-44-1.fc17: * should fix your issue, * was pushed to the Fedora 17 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing systemd-44-1.fc17' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2012-3918/systemd-44-1.fc17 then log in and leave karma (feedback). systemd-44-1.fc17 has been pushed to the Fedora 17 stable repository. If problems still persist, please make note of it in this bug report. systemd-37-19.fc16 has been submitted as an update for Fedora 16. https://admin.fedoraproject.org/updates/systemd-37-19.fc16 systemd-37-19.fc16 has been pushed to the Fedora 16 stable repository. If problems still persist, please make note of it in this bug report. |