Re: 'Operation not permitted ' when accessing shares files from User space audio driver
Re: 'Operation not permitted ' when accessing shares files from User space audio driver
- Subject: Re: 'Operation not permitted ' when accessing shares files from User space audio driver
- From: Tuviah Snyder <email@hidden>
- Date: Thu, 31 Jan 2013 20:04:55 +0000
- Thread-topic: 'Operation not permitted ' when accessing shares files from User space audio driver
Hi Joel,
Unfortunately that doesn't work because my application, which is writing the shared memory that the driver needs to read from, is not elevated and therefore cannot write to it. Any other way?
best,
Tuviah
On Jan 31, 2013, at 3:26 AM, Joel Reymont <email@hidden> wrote:
> Take a look at the entitlements and see if there's a directory you can coopt:
>
> /usr/share/sandbox/com.apple.audio.coreaudiod.sb
>
> I'm using /Library/Preferences/Audio to store my driver preferences,
> for example.
>
> From a cursory inspection, it looks like that's the only directory you
> can use without modifying the entitlements.
>
> On Thu, Jan 31, 2013 at 6:57 AM, Tuviah Snyder <email@hidden> wrote:
>> After reading some more, it looks like this is documented behavior in AudioDriverPlugin.h:-(
>>
>> Apparently coreaudiod sandboxes file access. Any way to work around this? What location can my unsandboxed app, which is not elevated (so cannot write to the drivers bundle) write memory mapped files to that would be readable by the plugin?
>>
>> Best
>> Tuviah
>>
>> Sent from my iPad
>>
>> On Jan 30, 2013, at 7:26 PM, "Tuviah Snyder" <email@hidden> wrote:
>>
>>> I'm working on a user mode audio driver based on NullAudio which will read audio from my application using shared memory. However any time I attempt to open a file, mutex, created by my other process I get 'operation not permitted,. Even if I explicitly set the permissions when creating it to 666 (read and write for all).
>>>
>>> I've previously had success writing a coremediaio DAL plugin (64 and 32 bit versions) using the same approach to pass video, and no issues. I executed the same code for reading audio from a terminal app compiled as 64 bit and no issues
>>>
>>> The only thing I can think of that can be causing this, is that the HAL audio plugin is running within coreaudiod which is executed by using -coreaudiod under a group of the same name.
>>>
>>> Anyone have any ideas how to resolve this.
>>>
>>> Best,
>>> Tuviah
>>
>> _______________________________________________
>> 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
>
>
>
> --
> --------------------------------------------------------------------------
> for hire: mac osx device driver ninja. kernel, usb and coreaudio drivers
> ---------------------+------------+---------------------------------------
> http://wagerlabs.com | @wagerlabs | http://www.linkedin.com/in/joelreymont
> ---------------------+------------+---------------------------------------
_______________________________________________
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