Sorry, haven't seen this reply... On Fri, Feb 5, 2010 at 00:32, Martin Gregorie <martin@xxxxxxxxxxxx> wrote: > On Thu, 2010-02-04 at 23:02 +0200, Gert van den Berg wrote: > >> Thanks... Someone with more than 5 minutes of *nix programming >> experience... ;) I actually hoped that a Perl script might be >> possible, but that seemed unlikely... (My C coding needs exercise and >> is usually restricted to microcontrollers...) >> > My C is the other way up to yours - the lowest level I've written C for > is my Microware OS-9 (68020) and Flex-09 (6809) systems - and I haven't > written 6809 C for a very long time. > > However, what are we trying to do? I'm asking because I'm not sure its > being achieved. In particular, you *must* use execve() to pass the > changed permissions along to a child process (in this case to wine.exe). > Then somebody would need to dig into Wine to know whether it passes them > on to the program we're asking it to run, since that's where they are > needed. exec and friends are quite new to me ;) The permissions involved here are at the CPU level though... > Is this something that would be better handled by other methods, i.e. by > changing the device file permissions? The obvious ways are, in ascending > order of difficulty: > To program / sys file are probably using in and out instructions to access the ports... It is the CPU itself denying the access, not the OS (but the OS can se up the initial permissions) See http://en.wikipedia.org/wiki/X86_instruction_listings#Original_8086.2F8088_instructions http://en.wikipedia.org/wiki/Protected_mode#Privilege_levels is what is blocking the instructions... Additional ports can be set to be accessible (which is what ioperm does (iopl lets the application run in ring 0, which gives it the same I/O access as the kernel)) I can't remember if the I/O permissions is at the ring level or at the process level... (probably a good time to have a look at the intel developer manual...) Gert
