Date: Sat, 16 Sep 2017 13:18:33 +0000 From: bugzilla-noreply@freebsd.org To: freebsd-bugs@FreeBSD.org Subject: [Bug 222258] renameat(2) capability error with absolute path names outside of a sandbox Message-ID: <bug-222258-8-be7XdbTZx6@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-222258-8@https.bugs.freebsd.org/bugzilla/> References: <bug-222258-8@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=222258 Jilles Tjoelker <jilles@FreeBSD.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|New |Open CC| |jilles@FreeBSD.org --- Comment #6 from Jilles Tjoelker <jilles@FreeBSD.org> --- (In reply to Ed Maste from comment #5) The block of code checking for CAP_UNLINKAT should not apply when an absolute path was originally passed to the system call. This is needed to maintain POSIX's requirement that renameat() be equivalent to rename() unless either old or new specifies a relative path. I don't immediately know how to code this best. The patch from Conrad Meyer seems wrong since capabilities are supposed to be enforced for all processes, not only ones in capability mode. This feature may be useful when passing file descriptors to a process with a lower privilege level. In any case, this seems a valid bug. -- 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-222258-8-be7XdbTZx6>