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:59:01 -0800
On Mar 28, 2006, at 12:36 PM, Ethan Funk wrote:
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.
I agree, except that the audio stops playing when the non-console
user that it is running under logs out. This is not acceptable
behavior for my application. If I could keep audio and midi
running after the user logs out, I would be very happy. Any idea
how to do that? I would happily abandon launchd and root user if I
could find a way to keep audio playing!
Why would this user ever need to log out?
At any rate, this is why I mentioned a user logged in via a non-
console session. That kind of session (which is what you get when you
run your daemon as root) is immune to the HAL's tracking of the
currently active user login stuff.
On the security side of things: I have implemented a user
privilege drop to a non-root user on processes that the server
forks when it is running as root. The only remaining security hole
I can think of is that the server can play any audio files on the
system with out regard to file permissions.
All I know is that I wouldn't want to be a vector of infection if I
can help it. Running code as root is just begging for it. Plus, it's
hard to nail down all the security issues in a large code base,
particularly if that code loads/uses other code you don't have
control over. The easiest way is to simply always run the code as a
less privileged user.
--
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