On Mon, Aug 29, 2011 at 08:44:39AM +1000, matthew green wrote: > > > I've just had my first occasion to play with the processor affinity > > code, via porting some code from linux. It was very straightforward, > > but there's one glaring difference: linux doesn't (by default, anyway) > > require root to use their sched_setaffinity(), while we do require root > > (by default) for pthread_setaffinity_np(). > > > > I don't pretend to understand the security ramifications regarding > > processor affinity; I do wonder, however, whether it warrants requiring > > elevated privilege (and possible exposure via other code in the process > > which doesn't require root for normal operation) to prevent allowing > > users to pin their own code to a particular cpu by default. Are we sure > > we've made the right (default) tradeoff here? > > > > For my own use, I know I can tweak the secmodel to permit > > KAUTH_PROCESS_SCHEDULER_SETAFFINITY . (and now I'm going to research > > how to actually do it. :) > > i've found this some what annoying. IMO, we should have a a way to say > "let normal users do this". i'm not sure sysctl is the right place, but > maybe an overlay secmodel? on some of my machines, i don't want to have > to be root to do this. it's annoying to have to use root to get the > highest performance i can out of an application. > > the current default is fine, however.
Something analogous to our friends: % sysctl -a | grep mount vfs.generic.usermount = 0 security.models.suser.usermount = 0 % perhaps? Regards, Alistair
