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/
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