lock file question

linas at austin.ibm.com linas at austin.ibm.com
Tue Nov 4 11:57:05 EST 2003


On Mon, Nov 03, 2003 at 03:32:15PM -0600, John Rose wrote:
>
> As part of a new RTAS interface, I'm writing a library that needs to
> manage mmap() use of a phys mem region in /dev/mem/.  If library user B
> requires an mmap()'ed buffer of a subset of this memory, then the
> library should ensure that it does not hand out a region being used by
> library user A.
>
> The current plan is to create a lock file "/var/lock/LCK..librtas", and
> use byte-range locks to manage the use of buffers that fall within this
> region.  When such a buffer is needed, the lock file will be probed to
> select an appropriate region for use.  The client function can then mmap
> /dev/mem with the confidence that it has exclusive control over the
> region.

Its not clear to me if security is a concern here.  A cracker could write
code that does this access and ignores the contents of /var/lock...
(or, more easily, starts client A, mv /var/lock/LCK..librtas /var/lock/bogus,
and then starts client b...)

Note also, if librtas is needed for 'day-to-day' sysadmin purposes,
then this interface might make it hard for any sysadmins who like
to run chrooted environments, virtual servers, etc or systems that use
anything other than plain-unix-root-user perms to get access to things.
(e.g. SELinux, RSBAC, etc.)

It would be painful for these people to set up systems where only the
trusted users would get access to /dev/mem rtas but not others...

> Does this seem like to right direction to go?  I'm under the impression

--linas

** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/





More information about the Linuxppc64-dev mailing list