Date: Wed, 22 May 2013 11:41:45 +0300 From: Konstantin Belousov <kostikbel@gmail.com> To: "Robert N. M. Watson" <rwatson@freebsd.org> Cc: arch@freebsd.org, Jilles Tjoelker <jilles@stack.nl> Subject: Re: Extending MADV_PROTECT Message-ID: <20130522084145.GJ3047@kib.kiev.ua> In-Reply-To: <EBB4BD28-B803-4E26-851F-1F47506DD7A9@freebsd.org> References: <201305071433.27993.jhb@freebsd.org> <5192AE7C.10105@FreeBSD.org> <20130520222825.GB43407@stack.nl> <201305211222.11236.jhb@freebsd.org> <EBB4BD28-B803-4E26-851F-1F47506DD7A9@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
--xApCgTs/B7u0zyQe Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, May 21, 2013 at 03:24:50PM -0400, Robert N. M. Watson wrote: >=20 > On 21 May 2013, at 12:22, John Baldwin wrote: >=20 > >> 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 n= ot > >> 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 no= t=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. M= y=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 t= han a=20 > > generic procctl()). >=20 > 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). I agree with statement that an ioctl()-like interface for the syscall is too wide, and I stated this already. On the other hand, I believe that e.g. ptrace(2) is fine as is, and splitting it into 20-30 syscalls each performing single ptrace operation would be a mistake. The same, IMO, holds for the procctl() syscall, which is better not split into pprotect(), then some improved version of pprotect() etc. I would prefer to not have proliferation of the FreeBSD-specific process-controlling syscalls, which could be cumulated in the single entry and single man page. --xApCgTs/B7u0zyQe Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (FreeBSD) iQIcBAEBAgAGBQJRnITIAAoJEJDCuSvBvK1BQVkP/12RqB+uQEuGdKY7Jz1etv2w oAYDiNKVwFFM8J/tBYnOQvMOeP09SY9XW2k8SABY18KNIS3xYvfcCmuA7gKJfnth nnslKZFsTvbOxhbaOZT50Y/0y+MzFspcsat9xmpngELhoPzEsHL46aBLrjpGyVm1 jvLDxXE1XLEpdL+HZS3xvdCfpXtl45WyyM6B4Zc3otApX+XqNUiDJ92l3jzmuyXn JKRZAKe+SIUQpoLCxErz2hjnz3JKz3npOxuM+lnVT8jf+PoMl4j3aBXFUeQinVFf aQFFVl86kllPQtXM78hT/itKNazRM96txjdhl2A21H+V44NSEwunJ0ZT2umBgbVN pvt2kZeEDWeSPK4W6tuiyHFqkFqMqWvByCZn1XQ09chXxO9mlSXEoYgB9HMmvj/z 8M5mpi7ZnsGCGE4e3e1PUyfV/Im4MPIQ7y4zOyxkQ3Z+DbfQv7hLUiIyS/HBTICC Tz8yV9ZHoPMOWMNOcs1V0I2j6oQplk64T6pvq5Cw5W7+PGopiffXmIcip4izcpjR sL8LRC/iK6DkXCw/d1DS8mFuWAhCPD38sf2i4WzuUlSd61vqWxDtXoKhBB4sjgkM ki8C1WGyKgtSB1xoHiGcUOKQFjwJKA8n9wZCbhn2gybrefT2D4PF5X0UJtIiy2AV +1xNFGuosOc92rcOicxp =/zkA -----END PGP SIGNATURE----- --xApCgTs/B7u0zyQe--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20130522084145.GJ3047>