Date: Tue, 21 May 2013 00:28:26 +0200 From: Jilles Tjoelker <jilles@stack.nl> To: John Baldwin <jhb@FreeBSD.org> Cc: Konstantin Belousov <kostikbel@gmail.com>, arch@freebsd.org Subject: Re: Extending MADV_PROTECT Message-ID: <20130520222825.GB43407@stack.nl> In-Reply-To: <5192AE7C.10105@FreeBSD.org> References: <201305071433.27993.jhb@freebsd.org> <201305090814.52166.jhb@freebsd.org> <20130509123147.GT3047@kib.kiev.ua> <201305101535.50633.jhb@freebsd.org> <20130514192115.GA34869@stack.nl> <5192AE7C.10105@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, May 14, 2013 at 05:37:00PM -0400, John Baldwin wrote: > On 5/14/13 3:21 PM, Jilles Tjoelker wrote: > > All this is not very important for process protection because it > > requires root privileges anyway but future procctl commands may well be > > accessible to normal users (I'm thinking of avoiding proliferation of > > pd* calls in particular). > I originally used that approach in pprotect() since that is what ktrace > uses. I did it this way in procctl() to err on the side of reporting > errors vs not, but I can easily change it. This is something I wasn't > sure of and very much appreciate feedback on. > Do you have any thoughts on having this be more ioctl-like ("automatic" > copyin/out and size encoded in cmd) vs ptrace-like (explicit sizes and > in/out keyed off of command)? 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_*. -- Jilles Tjoelker
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20130520222825.GB43407>