Date: Sun, 10 Aug 2008 10:38:03 +0100 (BST) From: Robert Watson <rwatson@FreeBSD.org> To: Peter Jeremy <peterjeremy@optushome.com.au> Cc: src-committers@freebsd.org, John Baldwin <jhb@freebsd.org>, cvs-src@freebsd.org, Ed Schouten <ed@freebsd.org>, cvs-all@freebsd.org, Kostik Belousov <kostikbel@gmail.com> Subject: Re: cvs commit: src/sys/dev/io iodev.c Message-ID: <alpine.BSF.1.10.0808101036440.85739@fledge.watson.org> In-Reply-To: <20080809114305.GV64458@server.vk2pj.dyndns.org> References: <200808081343.m78DhwYE068477@repoman.freebsd.org> <200808081226.32089.jhb@freebsd.org> <20080809001256.GL64458@server.vk2pj.dyndns.org> <alpine.BSF.1.10.0808091127170.36489@fledge.watson.org> <20080809103338.GN97161@deviant.kiev.zoral.com.ua> <alpine.BSF.1.10.0808091207350.16028@fledge.watson.org> <20080809114305.GV64458@server.vk2pj.dyndns.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, 9 Aug 2008, Peter Jeremy wrote:
> On 2008-Aug-09 12:08:42 +0100, Robert Watson <rwatson@freebsd.org> wrote:
>> While /dev/io appeals to the UNIX "everything is a file" sensibility, I
>> think the system calls we have for this on i386 are more conceptually
>> coherent.
>
> IMO, /dev/io is inherently a kludge - it's really more a MAC issue than
> anything like a file. Whilst you get a FD by opening /dev/io, you never use
> that FD for anything other than passing to close(2). Instead, you are using
> a magic side-effect that allows you to execute 'in' and 'out' instructions
> whilst you hold that FD open. AFAIK, the sole reason for having it appear
> as a file is that (in the absence of a MAC framework), the filesystem
> provides the only mechanism for access control. IMHO, /dev/io should be
> deprecated in favour of something like the MAC framework. (Note that
> i386_{g,s}et_ioperm(2) are nor suitable in their current form because there
> is no mechanism for the system administrator to define access controls).
Well, the MAC Framework is basically an object/method control mechanism, and
appropriate for use with different sorts of objects and methods (we have quite
a few). It doesn't specify how the service is delivered, though. What I like
about i386_{g,s}et_ioperm(2) is that they set qualities on a process (cleared
on exeve(2), I hope), and if we have different priv(9) privileges for them,
they can be separately controlled.
Robert N M Watson
Computer Laboratory
University of Cambridge
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?alpine.BSF.1.10.0808101036440.85739>