Re: Another approach to root user?
Re: Another approach to root user?
- Subject: Re: Another approach to root user?
- From: Ethan Funk <email@hidden>
- Date: Wed, 29 Mar 2006 13:28:53 -0700
No third party AU components are used by my daemon. The only components I am using are MatrixMixer, HALOutput and AUConverter for sample rate conversion. I do use QuickTime, but that is farther down the chain. I should mention that this problem come in fairly early on in my code. There isn't much that has been initialized yet other than a few pthread locks, the opening/binding of the tcp control socket, midi and the reading for a text preferences file.
I assume coreaudiod is run as root. If I run my daemon as root, it too has no problem, other than being a security danger. As I understand it, if my daemon runs as root even in it's own non-console session, it has access/permission to the global namespace, so it can connect to the window manager. Might this be why coreaudiod get's away with it?
Ethan...
On Mar 29, 2006, at 1:07 PM, Jeff Moore wrote: I was afraid that might happen. At any rate, what I think is going on is that in the course of initializing itself, the Component Manager is loading some or all of the system-global components into your daemon's process. Since these components might be for a variety of purposes, including UI related operations, one or more of them is inadvertently attempting to make a connection to the window server.
The question is, why does this happen to your daemon, but not to coreaudiod, which also loads AU's? I wonder if it's possible that you have one or more third party AU's (or other components) installed that are linking their view components in a non-daemon friendly way?
|
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Coreaudio-api mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden