> > Here's a proposal for a sysctl(7) knob to easily allow non-superusers to > > set the CPU affinity of processes and threads they own: > > > > security.secmodel.suser.usersetaffinity > > > > (ressembles the one already existing to allow for user mounts) > > > > Would it be acceptable to modify current secmodel_suser(9) to allow this? > > > > This issue comes regularly on various tech-* MLs, motivated by the fact > > that people expect this behavior based on what they encounter on other OS.
i like this idea. i didn't read the patch. > Just out of curiosity, but is it possible for the superuser to still > reserve wanted CPU/cores, such that non-privileged users could, if that > sysctl is enabled, work with the non-reserved ones? Or, can the > sysadmin specify CPU/cores and/or limits for non-privileged users? > > Since the default is to not allow affinity control, it's not of utmost > importance, but it could allow a compromise between total restriction > and total freedom... I have no objection to that sysctl personally. i think the default should be changed, but user-specified affinity shouldn't be considered an absolute rule, just a preference. i'm not sure i understand exactly what sort of issue you're envisioning. .mrg.