Skip site navigation (1)Skip section navigation (2)
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>