Re: CoreMIDI and sudo ...
Re: CoreMIDI and sudo ...
- Subject: Re: CoreMIDI and sudo ...
- From: Doug Wyatt <email@hidden>
- Date: Mon, 23 Sep 2002 17:31:08 -0700
John,
The problem has to do with permissions, Mach ports, and the bootstrap
server.
A root process can see the MIDIServer's Mach server ports no matter
which user owns it.
But User X can't see the ports of a MIDIServer owned by root. User X
will end up with his own copy of the MIDIServer, a pretty useless one
because all the hardware has been grabbed by root's MIDIServer.
I'd be glad to consider suggestions for how to improve this behavior
without creating security issues.
Doug
On Friday, Sep 6, 2002, at 17:03 US/Pacific, John Lazzaro wrote:
Hi everyone,
Integration of CoreMIDI support into sfront is in progress, an
interesting behavior popped up that I thought I send along ... the
hardware in this description is a PB 550 Mhz running 10.2, and an
Edirol UM-1S MIDI interface whose MIDI Out and MIDI In jacks are
looped with a MIDI cable. Except for the single source and destination
of the UM-1S, no other MIDI sources or destinations in the system.
Two processes are involved:
Process A: Creates a MIDI Input Port using MIDIInputPortCreate(),
then uses MIDIGetNumberOfSources(), MIDIGetSource(),
and MIDIPortConnectSource() to connect the UM-1 MIDI In
jack to the created input port (this process is the sa.c
program sfront creates ...).
Process B: Creates a MIDI Output Port using MIDIOutputPortCreate(),
use MIDIGetNumberOfDestinations() and MIDIGetDestination()
to find the only destination in the system (the UM-1S MIDI
Output Jack).
If both Process A and Process B are run by the same user,
everything works fine. The order of program startup doesn't seem
to matter (these are command-line programs executed from Terminal):
first A, then B, or vice-versa, produces a running system, where
Process B's MIDI commands are seen by Process A, and rendered into
audio.
However, if sudo is used to run Process A as root (useful so
that sfront can lock its pages into RAM ...), the order now
matters. If Process B is run first, and then A, things work well.
However, if Process A runs first, when Process B runs the loop
that should find a UM-1S destination:
for (i = 0; i < MIDIGetNumberOfDestinations(); i++)
if (outsrc = MIDIGetDestination(i))
return 0;
printf("No MIDI Destinations available\n");
return -1;
it prints the "No MIDI Destinations available" and exits.
I've seen similar "root ownership of Process A causes issues"
problems in a companion test setup, where instead of using a
looped-back external MIDI device, Process B sets up a virtual source
that Process A finds, but that setup is more complex to describe, so I
thought I would post the simple UM-1S example. Thanks in advance!
--
Doug Wyatt
work: email@hidden (CoreAudio)
personal: email@hidden
http://www.sonosphere.com
_______________________________________________
coreaudio-api mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/coreaudio-api
Do not post admin requests to the list. They will be ignored.