Date: Fri, 12 Nov 2021 12:05:58 +0000 From: bugzilla-noreply@freebsd.org To: bugs@FreeBSD.org Subject: [Bug 259770] ggate: jail(2) failure error: Unable to jail process in directory /var/empty after stable/12 src ca9ab8ea1774 Message-ID: <bug-259770-227-996BvX8bmI@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-259770-227@https.bugs.freebsd.org/bugzilla/> References: <bug-259770-227@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D259770 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 t= he 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 understand= ing 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 o= wn 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 unlin= k. 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. --=20 You are receiving this mail because: You are the assignee for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-259770-227-996BvX8bmI>