[Bug 259770] ggate: jail(2) failure error: Unable to jail process in directory /var/empty after stable/12 src ca9ab8ea1774

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

Mateusz Guzik <mjg@FreeBSD.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |mjg@FreeBSD.org

--- Comment #3 from Mateusz Guzik <mjg@FreeBSD.org> ---
But does this really work with the pwd_chroot_chdir_check_open_directories
hack?

To my reading the pidfile API keeps the dir fd open so that it can unlink the
file down the road. As /var/run is 755 you need root permissions to do it.

The patchset includes setuid to an unprivileged user which to my understanding
already prevents the functionality from working.

So let's say ggated stays running as a jailed root. If the /var/run dirfd is
let inside even with rights limited to unlinking files in that directory,
compromised ggated would be able to unlink evey file inside, not just its own
pidfile.

This could be worked around with a syscall which takes a path and a matching
file descriptor to prove you have the thing open and only then allows unlink.

I think this sufficiently demonstrates that:
1. passing dir fds inside is very error prone
2. managing pidfiles from a daemon of the sort is a bad idea

That said, in my opinion the best long term solution is to move pidfile
management out of any priv-dropping code.

I do have to note that the rc system has to tolerate stale pidfiles already
(e.g., what if the machine crashed and there was nobody to clean it up), so
perhaps in the meantime the pidfile API can grow a flag that the caller is not
going to do pidfile_remove and consequently dir fd is not needed.

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