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. >>=20 >> In either case, it is possible to have a P_PROCDESC to affect a = process >> by process descriptor. Capsicum may then need more CAP_*. >=20 > I talked to Robert about this in person at BSDCan and he indeed does = not=20 > prefer general purpose multiplexers for system calls. In particular = it does=20 > make auditing and access control for such things a lot harder to do. = My=20 > impression from my discussion with him is that he would actually = prefer much=20 > more narrowly focused system calls (so pprotect() in this case rather = than a=20 > 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>