https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=222632
--- Comment #12 from Ed Maste <ema...@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 connect
> 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 "Capsicum
overhaul" in r247602.
Thus it seems the original design intent was to allow connect(2) in capability
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.
--
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
