Re: CoreMIDI and sudo ...
Re: CoreMIDI and sudo ...
- Subject: Re: CoreMIDI and sudo ...
- From: Herbie Robinson <email@hidden>
- Date: Tue, 24 Sep 2002 03:04:57 -0400
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
You could implement a server queue facility based on the Mach
messaging. The idea would be to implement a file system nub
(something in /dev?) that users processes could open, but that was
really hooked up to a MIDIServer that was started when the system
booted. I don't know of any good implementations of server queues in
the Unix world -- client server architectures don't fit well with the
Unix I/O model. I've seen some really cumbersome attempts at server
queues using pipes and/or stream, but they were shall we say
extremely interesting. OTOH, Mach messaging looks like a perfect
foundation for it.
A server queue can be an object that is either published by the
server or the server queue can sit in the file system (this makes
client initialization easier and you can piggyback on the file
system's protection mechanisms). The client puts requests (data
records) into the queue and gets responses to requests back. I
believe mach messaging already does this. Where it gets interesting
is on the server end: Servers (in the general case, one needs to
allow for multiple servers on one queue) can read any number of
unused messages for processing and once they have read a message,
that message is locked by that server. When the server has finished
processing a message, it send a reply back to the client. For
security purposes, the OS collects identifying information about the
client (user id, privileges, process id, transaction id, etc) and
makes that data available to the servers when they read messages from
the clients. The server may use this information to validate the
client (or temporarily change user ids to operate on behalf of the
client). This is the part that would need to be layered on top of
Mach messaging.
If you have the server queue, the MIDI server could do setuid and
setgid to something innocuous when it started up (after initializing
the server queue) to keep things secure (even in the face of devious
plug-ins). Note that setting the effective user ids and group ids is
not a desirable option for any application that loads plug-ins,
because the plug-ins could revert to root and do devious things.
It's much safer to permanently change the UID and once he MIDI Server
had it's server queue open it doesn't need any special privileges.
The only downside to this would be you couldn't have per-user drivers
(which is kind of dubious anyway).
--
-*****************************************
**
http://www.curbside-recording.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.