Date: Tue, 22 May 2012 21:53:54 -0500 (CDT) From: Robert Bonomi <bonomi@mail.r-bonomi.com> To: freebsd-questions@freebsd.org, tomdean@speakeasy.org Subject: Re: Using inb() and outb() Message-ID: <201205230253.q4N2rsdN078363@mail.r-bonomi.com> In-Reply-To: <4FBC4B20.8070100@speakeasy.org>
next in thread | previous in thread | raw e-mail | index | archive | help
> From owner-freebsd-questions@freebsd.org Tue May 22 21:30:21 2012
> Date: Tue, 22 May 2012 19:27:44 -0700
> From: "Thomas D. Dean" <tomdean@speakeasy.org>
> To: freebsd-questions@freebsd.org
> Subject: Re: Using inb() and outb()
>
> On 05/22/12 17:09, Eitan Adler wrote:
> > On 22 May 2012 14:25, Thomas D. Dean<tomdean@speakeasy.org> wrote:
> >> On 05/22/12 14:08, Robert Bonomi wrote:
> >>
> >> That is what I thought.
> >>
> >> The entire operation will have to run as root. Nothing will be non-root.
> >
> > Can you make a SUID helper which only does the inb/outb operations as root?
> >
>
> I am planing to move the higher level functions to a driver.
>
> I really want a userland interface to the process.
It just occured to me -- you could do a 'daemon' process that ran as the
superuser, and provided the hardware-level services to a non-root client
via, say, RPC, or a bare 'socket' ('unix' or 'ip') connection.
Doing the I/O via RPC would be 'interesting', in that the 'device' could
be physically connected to one machine (almost an 'embedded'-class micro-
controller), while the vast majority of the 'control progrm' could run on
an entirely different machine.
If you're up to doing the device-driver coding, it is a =better= solution,
because then you can use the filesystem access-control mechanisms to limit
access to the 'device'.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201205230253.q4N2rsdN078363>