Date: Thu, 11 Nov 2021 19:05:46 +0000 From: bugzilla-noreply@freebsd.org To: bugs@FreeBSD.org Subject: [Bug 259778] Capsicum failures can raise only SIGTRAP Message-ID: <bug-259778-227-Zp7XlXVBBP@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-259778-227@https.bugs.freebsd.org/bugzilla/> References: <bug-259778-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=3D259778 Mark Johnston <markj@FreeBSD.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |markj@FreeBSD.org --- Comment #1 from Mark Johnston <markj@FreeBSD.org> --- I tend to agree that it's like not very useful to allow the signal number t= o be configured. Though, I wonder if it'd be nicer to add a new signal for this purpose, rather than overloading SIGSYS. Capsicum already has its own errno numbers after all. I'd be inclined to make the new mechanism an entirely separate procctl verb: - PROC_TRAPCAP_CTL is purely a debugging feature, while your mechanism is n= ot. - The TRAPCAP_CTL verb takes an int parameter, but maybe your mechanism wou= ld benefit from more flexibility. - I don't really like the idea of silently turning off PROC_TRAPCAP_CTL (or= the global kern.trap_on_enotcap sysctl for that matter). I think it wouldn't be very difficult to ensure that SIGTRAP is delivered first if both mechanisms= are configured... --=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-259778-227-Zp7XlXVBBP>