On 09/30/2013 04:43 PM, Felix Geyer wrote:
> On 30.09.2013 20:19, Jamie Strandboge wrote:
>>> +  owner @{HOME}/.nvidia/ rw,
>>> +  owner @{HOME}/.nvidia/** rwm,
>>
>> I've not seen 'm' for @{HOME}/.nvidia/** - this isn't ideal but 'ok' I guess.
>>
>>> +  owner /tmp/gl* m,
>>>
>> This I don't like this at all, especially since many will presumably use the
>> user-tmp abstraction with nvidia, and it intentionally avoids mmap (btw, I'm
>> pretty sure you would need 'mrw' here anyway). I came across this recently 
>> and
>> found that the app behaves fine without access to /tmp/gl* at all, so we are
>> explicitly denying it.
>>
>> Also, there is a bug on the nvidia GL libraries not honoring TMPDIR:
>> https://launchpad.net/bugs/1212425
>>
>> (aiui, that should be fixed soon)
> 
> The same seems to apply to @{HOME}/.nvidia/** m: applications request it
> but work fine even if it's denied.
> 
> Where are you explicitly denying it?
> Should this be done in the nvidia abstraction?
> Otherwise those DENIED errors would be annoying, especially when you
> are running aa-notify.
> 
I am denying in for click packages in apparmor-easyprof-ubuntu. I'm
uncomfortable adding an explicit deny rule to the policy because it can't be
undone if someone actually wants it (without not using the abstraction). If
others are ok with a deny rule in an abstraction, I won't strongly object.


-- 
Jamie Strandboge                 http://www.ubuntu.com/

Attachment: signature.asc
Description: OpenPGP digital signature

-- 
AppArmor mailing list
AppArmor@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/apparmor

Reply via email to