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: "Ben Gertzfield" <email@hidden>
- Date: Tue, 30 Oct 2007 16:02:53 -0700
Whoops; sorry for sending this twice. Meant to send my reply to the
whole list, not just Jeff.
First off, thanks so much for the speedy and informative reply!
On 10/30/07, Jeff Moore <email@hidden> wrote:
> The default device is a per-user setting, not a per-machine setting.
> So a process owned by root is going to potentially have a different
> default device than one owned by some other user.
The process isn't owned by root. It's owned by a user (the UID is set
to the user's UID); it's just that EUID is set to root so the process
can do privileged operations when needed.
> > On Tiger, this works correctly for setuid root processes.
>
> I just checked with HALLab. I see a different default device for the
> root user than for some other user.
You need to check with a setuid root binary, rather than checking as
the root user.
Setuid root binaries have UID and EUID set to different values; this
used to work in Tiger, and now has broken in Leopard.
> Note that the HAL's per-user settings will get confused in a program
> that calls seteuid(). This is because CFPreferences, the mechanism the
> HAL uses to store and retrieve the default device setting, has no way
> of know about the change in effective user ID. Consequently, your
> program needs to flush the CFPreferences caches manually.
Ah hah. Now we're getting somewhere. However, even if I call
CFPreferencesAppSynchronize(kCFPreferencesCurrentApplication) before
getting the output device, I get the wrong value.
> Alternately, there is also a property on the HAL's system object (that
> for some inexplicable reason is not in the public API) with the 4CC
> 'euid' that you can set to inform the HAL that you have called
> seteuid(). The value for the property is a UInt32, but the contents
> has no defined meaning. The act of setting it is all that is important.
>
> Note that on Leopard, the HAL has a different mechanism for figuring
> out the euid of a process which works around the need to tell it about
> the change in euid. This is likely why your code is now failing.
The HAL shouldn't be looking at changes in euid; it should be looking
at changes in the calling thread's uid. Was there a reason this
change was made?
Our process ensures that the calling thread's UID is set to the user
whose preferences we wish to obey when looking up the audio device.
Shouldn't this obey the Principle of Least Surprise?
Especially since this worked in Tiger, I'm just confused as to why the
EUID behavior changed without any accompanying release notes. Was I
unknowingly relying on an undocumented bug?
Ben
_______________________________________________
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