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: Tue, 28 Mar 2006 12:15:35 -0800
On Mar 28, 2006, at 7:29 AM, Ethan Funk wrote:
First, I'll just echo what Shaun Wexler said: daemons are pretty
much forbidden from making connections to the Window Server. The
reason why is that daemons really aren't supposed to have any UI
and, as such, should have no business with the Window Server. Not
only does this mean you need to avoid frameworks like Cocoa and
App Services, but also anything that indirectly uses those
frameworks as well, like AU view code. In fact, you might even
want to avoid using stdout and stderr since these streams might
point to /dev/null depending on when launchd launces your daemon.
I am not using a GUI. In fact, I close stdin, stdout and stderr
just for good measure even though launchd does this too. I am
really trying to make a daemon here. All user control is performed
through a tcp port.
The fact that you are seeing those log messages means that since you
aren't doing it directly, you must be pulling in some piece of
software that connects to the Window Server indirectly. Otherwise,
there wouldn't be a log message about the failed connection.
My guess is that this has little to do with the other problems you
mention, though.
Second, I have to ask about why you need a daemon in the first
place? The task the daemon is performing will have a direct impact
on whether it should run in the root bootstrap session or in a
particular user's login session or in some other place. You might
also want to go into some detail about how outside entities
interface with the daemon (if they are supposed to).
The big picture here is of a radio automation system. A server
does all the heavy lifting (automation, playlists, audio input and
file playing, segues, logging, streaming, recording, audio output,
etc). A client application (with GUI) connects to the server via a
tcp port to control things, either on the local machine or over an
network or both. There can be any number of clients connected
including zero. Even if no one is "logged in" the server MUST
keep things playing as required by the automation setup. Running
the "server" in a user login session would work only if that
session could be logged out and the server would keep running.
From my experiments, I can login to a new user session, open the
terminal, run my server (which detaches from the terminal session
via a fork call in the non-launchd version), and log out of the
user session. My server keeps running, although the audio via HAL
is muted. The server continues to play through the files in
silence. If I log back in as that original user, the audio springs
back to life. I am assuming that the HAL is getting some sort of
notification that the user has logged out and so it mutes. Is this
correct? I assume HAL must be tied to the login session, and that
is why (I assume again) it fails to initialize under launchd. Am I
on the right track here?
By running the server as root, via sudo in the above terminal
example, I can get around things, but it sure would be nice to get
launchd to do it with out the need for a startup script with the
root password in it!
I would _never_ run a server like this as root. The reason why is
that it is essentially a big giant security hole, especially since
anybody can send TCP packets to it to make it do things like fork
other processes. Plus, I can't see that a server like this has any
need of the power of root to do it's job anyway. Why take on such a
risk?
The right thing to do is to run this server as some user logged in
via a non-console session.
Finally, CoreMIDI is a per-user type thing. In particular, the
MIDI server itself is launched inside the user's login session.
I'm not sure what's going to happen when the MIDI server needs to
be launched outside of an actively logged in user's session. It
could work fine, but more likely it will confuse things a bit.
Hopefully Doug can clarify this for us.
I guess what I'm hearing is that I must have a user's login session
for the midi to work. I really want to have midi machine control
for starting/stopping things via hardware directly to the server,
but I guess if there is no other way, that functionality will have
to be moved to the client application.
Running the server as a user logged in via a non-console session
would also solve this problem.
--
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