Re: Leopard: AudioHardwareGetProperty on default output device doesn't work for setuid processes
Re: Leopard: AudioHardwareGetProperty on default output device doesn't work for setuid processes
- Subject: Re: Leopard: AudioHardwareGetProperty on default output device doesn't work for setuid processes
- From: Brian Willoughby <email@hidden>
- Date: Tue, 30 Oct 2007 14:41:46 -0700
Hello Ben,
Since your audio suite is running as multiple users, it's not
terribly surprising that the audio preferences from a single user are
not affecting code running as the root user. What would happen if
multiple users log in? Why not simply have a separate configuration
setting for your setuid root process which indicates the desired
device? I'm sure it's convenient from the users viewpoint to track
the default audio device, but there is nothing stopping you from
having your own selection setting, perhaps with a UI for the end user
to pick from a list. Alternatively, once you've created an
independent setting for your setuid root process, you can always
create a user-level program which properly tracks the users audio
device preference and then copies it on to your custom setting along
with some form of notification.
What are the privileged operations that you must do? Perhaps there
are better ways to accomplish what you're currently doing as root.
If you rework your system to avoid root access, then you'll have a
safer application and also avoid issues with tracking the default
device of one console user among potentially many. Even if you get
your original design to work, there is always the possibility that
more than one user will log in and this will affect your delicate setup.
Brian Willoughby
Sound Consulting
On Oct 30, 2007, at 13:46, Ben Gertzfield wrote:
Hi folks,
I'm working on a bug where (on Leopard only) our software's audio always
plays sound out the default audio device, instead of the device the
user has selected in System Preferences. Our software uses a helper
background process that's set-uid root, as it needs to do privileged
operations.
I tracked the problem down to AudioHardwareGetProperty() always
returning AudioObjectID 0x10A (Built-in Output) on Leopard for
processes that are setuid root, no matter what the user has selected.
On Tiger, this works correctly for setuid root processes.
I've submitted bug 5568847 to track this issue, but I'm looking for a
workaround.
Does anyone know any possible workarounds for this issue? So far,
we've come up with:
1) Drop effective UID root process-wide before calling
AudioHardwareGetProperty(). We can't use this for our helper process,
as it needs to regain EUID root, and it's multithreaded, so we can't
affect other threads in the process.
2) Using fork() then seteuid(), then call AudioHardwareGetProperty().
We can't use this, as it spews hundreds of lines like:
The process has forked and you cannot use this CoreFoundation
functionality safely. You MUST exec().
Break on
__THE_PROCESS_HAS_FORKED_AND_YOU_CANNOT_USE_THIS_COREFOUNDATION_FUNCTION
ALITY___YOU_MUST_EXEC__()
to debug.
3) Write a audio device helper program for our helper program. Use
fork(), then seteuid(), then exec the audio device helper program.
This solution is subpar, because we can't be notified of default audio
device changes, unless we either poll or set up a communication
protocol between the two processes.
Thanks,
Ben Gertzfield
_______________________________________________
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