Re: Another approach to root user?
Re: Another approach to root user?
- Subject: Re: Another approach to root user?
- From: Jeff Moore <email@hidden>
- Date: Wed, 29 Mar 2006 12:50:41 -0800
I think you misunderstand what I was saying. As I understand it, when
you call FindNextComponent (and apparently the other component look
up routines too), the Component Manager has to build a list of the
currently registered components. As such, it will go through and
register in the process all the components, even ones totally
unrelated to what you are doing. Some of these components require
that the Component Manager call the component's Register method as
part of this process. This forces the Component Manager to load and
link the code for at least some of the components on your system.
What I was proposing was that since I don't see this happening when
coreaudiod launches on my own machine (which has a stock install of
10.4.5 on it), there may be some other component on your system that
I don't have on mine that is triggering this message as part of the
component registration process. One possible way this could happen is
if you have some AU that doesn't properly separate it's view
components from it's processing components. Hence my question. What
AU's your app is actually using is beside the point I think.
That said, you mention that you are using QT. I think that this is
the likely culprit as QT links in all sorts of UI related stuff. I
know that the QT folks have done work on their footprint, but I don't
know if they have gotten to the point where they are totally daemon
safe.
One thing you might want to do is to use tools like otool to snoop
through your binary and the binaries it links against to look for
what is loading the code that attempts to make the Window Server
connection.
On Mar 29, 2006, at 12:28 PM, Ethan Funk wrote:
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?
--
Jeff Moore
Core Audio
Apple
_______________________________________________
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