[Bug 223327] dhclient: close the pidfile before calling chroot(2)

bugzilla-noreply at freebsd.org bugzilla-noreply at freebsd.org
Sat Nov 18 22:06:53 UTC 2017


https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=223327

Jilles Tjoelker <jilles at FreeBSD.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jilles at FreeBSD.org
             Status|New                         |Open

--- Comment #2 from Jilles Tjoelker <jilles at FreeBSD.org> ---
Although kern.chroot_allow_open_directories can be bypassed trivially via Unix
domain socket file descriptor passing, it does serve a purpose in pointing out
open chroots and jails like this one. The open directory allows full access to
the / that dhclient was started from, defeating its chroot to /var/empty. In
capability mode where ".." is disallowed, there is still full access to
/var/run.

It looks like the status quo is that the pidfile will not be removed when
dhclient aborts after chrooting. The pidfile_remove() call will always fail.
Before r322369 this was the case because of the chroot, and after r322369 this
was the case because dhclient limits the pidfile descriptor to no rights (so
that pidfile_verify() will fail).

If this status quo is acceptable, the fix is to close the directory file
descriptor using a newly added pidfile(3) function.

If the status quo is not acceptable, it could be fixed by adding a not chrooted
non-capmode intermediate process to do the remove or by moving the dhclient
pidfile into its own directory and fixing the rights on the pidfile and
directory descriptors. The latter also requires an addition to the pidfile(3)
API.

-- 
You are receiving this mail because:
You are the assignee for the bug.


More information about the freebsd-bugs mailing list