LogicalChaos has asked for the wisdom of the Perl Monks concerning the following question:

I have a module which requires interaction with custom hardware using inb and outb (and ioperm) on linux. Currently, I'm using separately compiled C programs with the owner as root and suid to provide the interface to the hardware.

I would like to bring the hardware interaction within the perl module for ease of installation, but don't know how to go about doing this. The module and scripts which use it need to run as the real user, not root.

I've tried mucking with Inline::C and XS, and have found no way to meet my requirements of running as the user, yet still accessing hardware. My only thought now is to release the code as a C 'package' which knows how to make/test/install the perl module, and allow the Makefile to setup the executables correctly.

Any thoughts/suggestions/experience to confirm or deny?

Thanks,
Rob

Replies are listed 'Best First'.
Re: Module with ioperm/inb/outb usage?
by Zaxo (Archbishop) on Dec 26, 2002 at 06:54 UTC

    Your assessment of the situation is commendably clear and correct.

    The usual way to deal with situations like this is to have a child process which runs suid from a root owned file, and is carefully constructed to only assert high privilege where needed. A typical example is a device driver which asserts privilege only to change state, and serializes inputs by connection, preventing interactions.

    XS or Inline::C are very likely to be useful in obtaining that. Neither is portable while there exists an OS which officially considers any but their own programming to be pure poison.

    After Compline,
    Zaxo

      Thanks for the confirmation.

      Interestingly enough, you answered a slightly different question than I thought I asked. I was thinking of creating the executables from a standard Makefile, in addition to installing the module.

      Your comment opened the possibility of still having all code within the module, and having the Makefile change permissions on the appropriate files, rather than building the executables directly.

      Thanks,
      Rob