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>