Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 496198 - net-dns/bind-9.9.3_p2 - no chroot jail using systemd
Summary: net-dns/bind-9.9.3_p2 - no chroot jail using systemd
Status: RESOLVED OBSOLETE
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: [OLD] Server (show other bugs)
Hardware: All Linux
: Normal enhancement (vote)
Assignee: Gentoo systemd Team
URL:
Whiteboard:
Keywords: NeedPatch
Depends on:
Blocks:
 
Reported: 2013-12-27 17:43 UTC by Evert
Modified: 2020-02-23 12:28 UTC (History)
3 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Evert 2013-12-27 17:43:54 UTC
net-dns/bind-9.9.3_p2 - chroot jail not implemented for systemd.
/usr/lib64/systemd/system/named.service just starts the named daemon:
ExecStart=/usr/sbin/named -u named $OPTIONS

Reproducible: Always

Steps to Reproduce:
1.configure bind to use a chroot jail
2.systemctl start named
3.ps -fu named
4.mount | grep chroot
Actual Results:  
# ps -fu named
UID        PID  PPID  C STIME TTY          TIME CMD
named     5985     1  0 17:18 ?        00:00:00 /usr/sbin/named -u named

# findmnt | grep chroot
[no output]


Expected Results:  
$ ps -fu named
UID        PID  PPID  C STIME TTY          TIME CMD
named    23618     1  0 dec20 ?        00:01:00 /usr/sbin/named -u named -t /chroot/dns

# findmnt | grep chroot
[should show the chroot mounts]

The chroot feature just doesn't seem to be implemented for systemd.

I was thinking to set the severity to major since a security feature has been broken. On the other hand, it just works so it could be minor too. So... I'll leave it in the middle: Normal ;)
Comment 1 Christian Ruppert (idl0r) gentoo-dev 2014-01-28 22:13:51 UTC
I'm sorry but I don't have/use systemd so someone else will have to take a look at it.

Perhaps the systemd team might be interested so CC'ing them.
Comment 2 Mike Gilbert gentoo-dev 2014-01-28 22:47:00 UTC
I would call this an enhancement request.

We would need to look at a more "systemd-ish" way of implementing this; the openrc init script does a lot of setup work that just is not feasible to do in a systemd service unit.
Comment 3 Evert 2014-01-28 23:09:10 UTC
OpenRC can do this so I'd call this a security issue ;)
Anyway, I think the way to go is using a lxc container.
Comment 4 Pacho Ramos gentoo-dev 2014-02-02 12:13:29 UTC
Arch uses a similar approach as us:
https://projects.archlinux.org/svntogit/community.git/tree/trunk/named.service?h=packages/bind

Fedora does some magic for chroot stuff, relying on an external script:
http://pkgs.fedoraproject.org/cgit/bind.git/tree/
Comment 5 Duncan 2014-03-12 18:50:00 UTC
(In reply to Mike Gilbert from comment #2)
> I would call this an enhancement request.
> 
> We would need to look at a more "systemd-ish" way of implementing this; the
> openrc init script does a lot of setup work that just is not feasible to do
> in a systemd service unit.

I'm just getting into systemd now and it's still a bit overwhelming, but looking at the systemd for admins blog-story series, systemd actually has available besides chroot (which is indeed available) an "even better than chroot" alternative available using kernel namespaces.

http://0pointer.de/blog/projects/changing-roots.html

Perhaps that could be put in the URL field?

Highlights:

* Chroots covered using RootDirectory (for the chroot) and ExecStartPre (for the pre-exec directory-setup script).

Also available using namespaces (and thus requiring enabling the appropriate kconfig options):

* ReadOnlyDirectories, InaccessibleDirectories

* PrivateTmp, PrivateNetwork, PrivateDevices (see the systemd.exec manpage, also linked from the above changing-roots blog-story)

* systemd-nspawn, a lightweight namespace creation tool.  (The description compares it to LXC saying systemd-nspawn is the gnome3 of container solutions, slick and easy but limited options, while LXC is the kde of container solutions, "more configuration options than lines of code.")


Given the above features, either a direct chroot implementation or a containers-based implementation should be doable without /too/ much trouble and it /looks/ like it might even be simpler than the openrc solution. If nobody else has gotten there first by the time I get comfortable with systemd I might try creating and posting a preliminary systemd-style solution myself, but it's anyone's guess how soon (or not) I'd get to it.  With any luck someone else will get to it first and I'll be spared the trouble. =:^\

Duncan
Comment 6 Duncan 2014-04-07 23:14:11 UTC
(In reply to Duncan from comment #5)
> (In reply to Mike Gilbert from comment #2)
> > We would need to look at a more "systemd-ish" way of implementing this
> 
> If nobody else has gotten there first by the time I get comfortable [...]

OK, it's actually quite easy.

*IF* you have the mount-binds already setup in your fstab, as I did, so systemd is picking up the mount-binds from there and doing the mounting already, it's as easy as a three-line file dropped in /etc/systemd/system/named.service.d, tho with commments mine's actually a bit longer...

You can name the file as you like, as long as it's in the standard local service-file modifications location (/etc/systemd/system/named.service.d), and ends with the *.conf extension.  Since it's the execstart line I modified, that's what I called my file here:

/etc/systemd/system/named.service.d/execstart.conf :

[Service]
ExecStart=
ExecStart=/usr/sbin/named -f -u named -t /path/to/chroot


That's all there is to it.  =:^)

1) The [Service] line says it's that section in the service file.

2) The empty ExecStart= line resets that line from the default service file, /usr/share/systemd/system/named.service, so it can be replaced by a new version.

3) The ExecStart=command line is the new version.  If you compare it to the ExecStart= line in the original file, all I've done is add the -t and the chroot path.

Tho as I mentioned my file is actually a little longer.  It has the original ExecStart= line copied as a reference comment (marked with the usual #), and  other comments explaining all the commandline options it uses, as well as one additional command-line option (-4, for IPv4 only), while I'm at it.

Here's the file as it actually appears here, complete with custom chroot path (/m/cbind):

[Service]
# original: ExecStart=/usr/sbin/named -f -u named
# f=foreground
# u=user
# 4=IPv4
# t=chroot
ExecStart=
ExecStart=/usr/sbin/named -f -u named -4 -t /m/cbind


For reference, here's what the normal fstab entries with the same chroot path would look like (mine's rather more customized but I'd have to explain it...)  And if you set logging to syslog in /etc/bind/named.conf and/or used -g instead of -f in the command above to log it to journald via STDERR, you could get away without the log entry too, making things pretty simple! (If you point a couple more settings away from /run in the config file, you can get away without it too, leaving only /etc/bind and /var/bind as bind-mounts! =:^)

/etc/bind      /m/cbind/etc/bind      none  bind 0 0
/run/named     /m/cbind/run/named     none  bind 0 0
/var/bind      /m/cbind/var/bind      none  bind 0 0
/var/log/bind  /m/cbind/var/log/bind  none  bind 0 0

A couple lines in /etc/fstab and a three line config-modifier file in /etc/systemd/system/named.service.d, *MUCH* simpler than the openrc based initscript method! =:^)

Duncan
Comment 7 Nico Baggus 2015-08-18 19:22:24 UTC
Hm this can be done with bind mounts also, as difficult as systemd does.
but it was chosen appearantly to not polute the fstab with a lot of entries that are used for one special case...

systemd isn't special in that respect....