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: Jeff Moore <email@hidden>
- Date: Tue, 30 Oct 2007 16:11:04 -0700
On Oct 30, 2007, at 4:02 PM, Ben Gertzfield wrote:
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!
Sent my response off-line too, but repeated here for posterity and
better editing =)
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.
Owned by root. Called seteuid(). It is all the same at the end of the
day in this situation.
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.
Basically, there's no need to check something like this because it is
expected to behave based on the euid not the uid of the process.
That's pretty much how all this sort of stuff has always worked on the
system.
Setuid root binaries have UID and EUID set to different values;
This is true, but irrelevant.
this used to work in Tiger, and now has broken in Leopard.
No it didn't. Your code is broken there too under the right
circumstances. Besides, it is relying on what is definitely a short
coming in the Tiger HAL in that it can't auto-detect the change in
euid, which it can do on 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.
That ain't how you do it. You are just flushing the per-user, per-
application prefs. You need to use CFPreferencesSynchronize across
basically all of it's domains.
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?
User actions and security checks are done with the euid. This is how
preferences and settings have always been managed on the system. The
uid has no bearing on the subject and never has. This is the bad
assumption you've been making.
--
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