Date: Tue, 21 May 2013 15:24:50 -0400 From: "Robert N. M. Watson" <rwatson@freebsd.org> To: John Baldwin <jhb@FreeBSD.org> Cc: Konstantin Belousov <kostikbel@gmail.com>, arch@freebsd.org, Jilles Tjoelker <jilles@stack.nl> Subject: Re: Extending MADV_PROTECT Message-ID: <EBB4BD28-B803-4E26-851F-1F47506DD7A9@freebsd.org> In-Reply-To: <201305211222.11236.jhb@freebsd.org> References: <201305071433.27993.jhb@freebsd.org> <5192AE7C.10105@FreeBSD.org> <20130520222825.GB43407@stack.nl> <201305211222.11236.jhb@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 21 May 2013, at 12:22, John Baldwin wrote: >> If it is ioctl-like, it is possible to redirect ioctl() on a process >> descriptor to procctl and use cap_ioctls_limit() infrastructure. I'm not >> sure Capsicum people actually like that, though. >> >> In either case, it is possible to have a P_PROCDESC to affect a process >> by process descriptor. Capsicum may then need more CAP_*. > > I talked to Robert about this in person at BSDCan and he indeed does not > prefer general purpose multiplexers for system calls. In particular it does > make auditing and access control for such things a lot harder to do. My > impression from my discussion with him is that he would actually prefer much > more narrowly focused system calls (so pprotect() in this case rather than a > generic procctl()). Yes -- based on experience with Capsicum, audit, but also things like ktrace, LD_PRELOAD, etc, I have a strong preference for not using ioctl for first-class (global) functions. We shouldn't go crazy on new system calls, but key new abstraction functions in the kernel do reasonably deserve new APIs. Matching pprotect() and pdprotect() APIs sound plausible to me (without skimming back through the thread too much). Robert
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?EBB4BD28-B803-4E26-851F-1F47506DD7A9>