Date: Thu, 12 Oct 2017 17:57:38 +0000 From: bugzilla-noreply@freebsd.org To: freebsd-bugs@FreeBSD.org Subject: [Bug 222632] Enable Capsicum for connect(2) Message-ID: <bug-222632-8-t4CJEg0tuq@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-222632-8@https.bugs.freebsd.org/bugzilla/> References: <bug-222632-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=3D222632 --- Comment #12 from Ed Maste <emaste@freebsd.org> --- > There does seem to be a discrepancy across the documentation and what is > actually implemented, as CAP_CONNECT explicitly states that connect(2) is > allowed and the check is in place in the actual implementation, but conne= ct > is not present in sys/kern/capabilities.conf, resulting in ECAPMODE. Indeed, it appears there is a discrepancy between what's implemented, what = is documented, and what we believe the expected behaviour should be. Descriptions from sys/capsicum.h: /* Allows for connect(2). */ #define CAP_CONNECT CAPRIGHT(0, 0x0000000080000000ULL) /* Allows for connectat(2) on a directory descriptor. */ #define CAP_CONNECTAT (CAP_LOOKUP | 0x0000010000000000ULL) #define CAP_SOCK_CLIENT \ (CAP_CONNECT | CAP_GETPEERNAME | CAP_GETSOCKNAME | CAP_GETSOCKOPT |= \ CAP_PEELOFF | CAP_RECV | CAP_SEND | CAP_SETSOCKOPT | CAP_SHUTDOWN) And reference "Declare more capability method rights" in r224255 and "Capsi= cum overhaul" in r247602. Thus it seems the original design intent was to allow connect(2) in capabil= ity mode subject to CAP_CONNECT on the socket, but it was never added to capabilities.conf. With later refinement on thoughts on ambient authority connect() does not fit into that model and thus would not be allowed in capability mode. --=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-222632-8-t4CJEg0tuq>