Re: sysctl(7) knob to allow users to control CPU affinity
On Thu, 3 Nov 2011 03:33:02 -0400, Matthew Mondor wrote: 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. I assumed there could be issues since pset(3) is restricted to the superuser (as well as pthread_setaffinity_np(3) now), but when rethinking about it I admit not seeing a problem as non-privileged processes cannot change the process priority beyond their class' priority. The only other case that comes to my mind would be a dmover(9) like system eventually reserving processor(s) for dedicated tasks, but I guess that in this case the reserved cores would simply be made unavailable in cpuctl(8)/pset(3)/etc... What do you mean? A unified resource control API for kernel and userland processes/LWPs? -- Jean-Yves Migeon jeanyves.mig...@free.fr
Re: sysctl(7) knob to allow users to control CPU affinity
On Thu, 03 Nov 2011 17:01:48 +1100 matthew green wrote: > > 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. I assumed there could be issues since pset(3) is restricted to the superuser (as well as pthread_setaffinity_np(3) now), but when rethinking about it I admit not seeing a problem as non-privileged processes cannot change the process priority beyond their class' priority. The only other case that comes to my mind would be a dmover(9) like system eventually reserving processor(s) for dedicated tasks, but I guess that in this case the reserved cores would simply be made unavailable in cpuctl(8)/pset(3)/etc... -- Matt
re: sysctl(7) knob to allow users to control CPU affinity
> > 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.
Re: sysctl(7) knob to allow users to control CPU affinity
On Thu, 03 Nov 2011 01:50:49 +0100 Jean-Yves Migeon wrote: > 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. 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. Thanks, -- Matt
sysctl(7) knob to allow users to control CPU affinity
Title says it all.
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.
--
Jean-Yves Migeon
j...@netbsd.org
Index: share/man/man9/secmodel_suser.9
===
RCS file: /cvsroot/src/share/man/man9/secmodel_suser.9,v
retrieving revision 1.4
diff -u -p -r1.4 secmodel_suser.9
--- share/man/man9/secmodel_suser.9 3 Oct 2009 07:37:01 - 1.4
+++ share/man/man9/secmodel_suser.9 3 Nov 2011 00:44:09 -
@@ -76,8 +76,17 @@ Finally, the flags
and
.Cm nodev
must be given for non-superuser mounts.
+.It security.models.suser.usersetaffinity
+Allow non-superuser users to control CPU
+.Xr affinity 3 .
+.Pp
+If non-zero, a non-superuser user can control the CPU
+.Xr affinity 3
+of the processes and threads he owns.
.El
.Sh SEE ALSO
+.Xr affinity 3 ,
+.Xr sched 3 ,
.Xr kauth 9 ,
.Xr secmodel 9 ,
.Xr secmodel_bsd44 9
Index: lib/libpthread/affinity.3
===
RCS file: /cvsroot/src/lib/libpthread/affinity.3,v
retrieving revision 1.6
diff -u -p -r1.6 affinity.3
--- lib/libpthread/affinity.3 9 Jul 2010 20:58:38 - 1.6
+++ lib/libpthread/affinity.3 3 Nov 2011 00:44:12 -
@@ -65,6 +65,21 @@ Note that
must be created and initialized using the
.Xr cpuset 3
functions.
+.Sh IMPLEMENTATION NOTES
+Setting CPU
+.Xr affinity 3
+requires superuser privileges.
+Non-superuser users can be allowed to control the affinity
+of their threads via
+.Xr secmodel 9 .
+See
+.Xr secmodel_suser 9 .
+.Pp
+Portable applications should not use the
+.Fn pthread_setaffinity_np
+and
+.Fn pthread_getaffinity_np
+functions.
.Sh RETURN VALUES
The
.Fn pthread_setaffinity_np
Index: lib/librt/sched.3
===
RCS file: /cvsroot/src/lib/librt/sched.3,v
retrieving revision 1.10
diff -u -p -r1.10 sched.3
--- lib/librt/sched.3 25 Apr 2011 23:14:33 - 1.10
+++ lib/librt/sched.3 3 Nov 2011 00:44:12 -
@@ -148,6 +148,15 @@ into the
.Fa cpuset .
.El
.Sh IMPLEMENTATION NOTES
+Setting CPU
+.Xr affinity 3
+requires superuser privileges.
+Non-superuser users can be allowed to control the affinity
+of their processes via
+.Xr secmodel 9 .
+See
+.Xr secmodel_suser 9 .
+.Pp
Portable applications should not use the
.Fn sched_setaffinity_np
and
Index: sys/secmodel/suser/secmodel_suser.c
===
RCS file: /cvsroot/src/sys/secmodel/suser/secmodel_suser.c,v
retrieving revision 1.34
diff -u -p -r1.34 secmodel_suser.c
--- sys/secmodel/suser/secmodel_suser.c 29 Dec 2009 04:25:30 - 1.34
+++ sys/secmodel/suser/secmodel_suser.c 3 Nov 2011 00:44:13 -
@@ -56,6 +56,7 @@ __KERNEL_RCSID(0, "$NetBSD: secmodel_sus
MODULE(MODULE_CLASS_SECMODEL, suser, NULL);
+static int secmodel_suser_usersetaffinity;
static int secmodel_suser_curtain;
/* static */ int dovfsusermount;
@@ -109,6 +110,14 @@ sysctl_security_suser_setup(struct sysct
NULL, 0, &dovfsusermount, 0,
CTL_CREATE, CTL_EOL);
+ sysctl_createv(clog, 0, &rnode, NULL,
+ CTLFLAG_PERMANENT|CTLFLAG_READWRITE,
+ CTLTYPE_INT, "usersetaffinity",
+ SYSCTL_DESCR("Whether unprivileged users may control "
+ "CPU affinity"),
+ NULL, 0, &secmodel_suser_usersetaffinity, 0,
+ CTL_CREATE, CTL_EOL);
+
/* Compatibility: security.curtain */
sysctl_createv(clog, 0, NULL, &rnode,
CTLFLAG_PERMANENT,
@@ -151,6 +160,7 @@ void
secmodel_suser_init(void)
{
secmodel_suser_curtain = 0;
+ secmodel_suser_usersetaffinity = 0;
}
void
@@ -494,6 +504,13 @@ secmodel_suser_process_cb(kauth_cred_t c
p = arg0;
switch (action) {
+ case KAUTH_PROCESS_SCHEDULER_SETAFFINITY:
+ if (secmodel_suser_usersetaffinity != 0) {
+ if (kauth_cred_uidmatch(cred, p->p_cred))
+ result = KAUTH_RESULT_ALLOW;
+ }
+ break;
+
case KAUTH_PROCESS_SIGNAL:
case KAUTH_PROCESS_KTRACE:
case KAUTH_PROCESS_PROCFS:
@@ -501,7 +518,6 @@ secmodel_suser_process_cb(kauth_cred_t c
case KAUTH_PROCESS_SCHEDULER_GETPARAM:
case KAUTH_PROCESS_SCHEDULER_SETPARAM:
case KAUTH_PROCESS_SCHEDULER_GETAFFINITY:
- case KAUTH_PROCESS_SCHEDULER_SETAFFINITY:
case KAUTH_PROCESS_SETID:
c
