All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dhaval Giani <dhaval@linux.vnet.ibm.com>
To: Corey Hickey <bugfood-ml@fatooh.org>
Cc: Peter Zijlstra <peterz@infradead.org>,
	linux-kernel@vger.kernel.org,
	Bharata B Rao <bharata@linux.vnet.ibm.com>,
	Balbir Singh <balbir@in.ibm.com>,
	Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>,
	Ingo Molnar <mingo@elte.hu>,
	mtk.manpages@gmail.com
Subject: Re: RT scheduling and a way to make a process hang, unkillable
Date: Tue, 17 Feb 2009 15:45:43 +0530	[thread overview]
Message-ID: <20090217101542.GB15989@linux.vnet.ibm.com> (raw)
In-Reply-To: <20090217050033.GA10409@linux.vnet.ibm.com>

> This was on top of tip I think. But yeah, that would be expected.
> Yesterday was really not working out, I figured out this one, and had
> fixed this in the next version. I have a better patch arond here.
> 

This is on top of tip, and should have everything fixed up.

/me has his fingers crossed :)


sched: Don't allow setuid to succeed if the user does not have rt bandwidth

Corey Hickey reported that on using setuid to change the uid of a
rt process, the process would be unkillable and not be running.
This is because there was no rt runtime for that user group. Add
in a check to see if a user can attach an rt task to its task group.

Changes from v5:
1. free up the user struct on failure
2. Use the user struct obtained in set_user
3. Change the return value to ENOSPC, since this makes more sense, we do
not have RT runtime available to us.

Changes from v4:
1. Check if find_user returns a valid user struct.

Changes from v3:
1. Actually fix the leak.

Changes from v2:
1. Patch compiles for CONFIG_CGROUP_SCHED as well
2. Fix two memory leaks.

Changes from v1:
1. Peter suggested that rt_task_can_change_user should be renamed to
task_can_change_user
2. Changed sched_rt_can_attach to boolean.

Signed-off-by: Dhaval Giani <dhaval@linux.vnet.ibm.com>


Index: linux-2.6/include/linux/sched.h
===================================================================
--- linux-2.6.orig/include/linux/sched.h
+++ linux-2.6/include/linux/sched.h
@@ -2320,9 +2320,13 @@ extern long sched_group_rt_runtime(struc
 extern int sched_group_set_rt_period(struct task_group *tg,
 				      long rt_period_us);
 extern long sched_group_rt_period(struct task_group *tg);
+extern int sched_rt_can_attach(struct task_group *tg, struct task_struct *tsk);
 #endif
 #endif
 
+extern int task_can_switch_user(struct user_struct *up,
+					struct task_struct *tsk);
+
 #ifdef CONFIG_TASK_XACCT
 static inline void add_rchar(struct task_struct *tsk, ssize_t amt)
 {
Index: linux-2.6/kernel/sched.c
===================================================================
--- linux-2.6.orig/kernel/sched.c
+++ linux-2.6/kernel/sched.c
@@ -9466,6 +9466,16 @@ static int sched_rt_global_constraints(v
 
 	return ret;
 }
+
+int sched_rt_can_attach(struct task_group *tg, struct task_struct *tsk)
+{
+	/* Don't accept realtime tasks when there is no way for them to run */
+	if (rt_task(tsk) && tg->rt_bandwidth.rt_runtime == 0)
+		return 0;
+
+	return 1;
+}
+
 #else /* !CONFIG_RT_GROUP_SCHED */
 static int sched_rt_global_constraints(void)
 {
@@ -9559,8 +9569,7 @@ cpu_cgroup_can_attach(struct cgroup_subs
 		      struct task_struct *tsk)
 {
 #ifdef CONFIG_RT_GROUP_SCHED
-	/* Don't accept realtime tasks when there is no way for them to run */
-	if (rt_task(tsk) && cgroup_tg(cgrp)->rt_bandwidth.rt_runtime == 0)
+	if (!sched_rt_can_attach(cgroup_tg(cgrp), tsk))
 		return -EINVAL;
 #else
 	/* We don't support RT-tasks being in separate groups */
Index: linux-2.6/kernel/user.c
===================================================================
--- linux-2.6.orig/kernel/user.c
+++ linux-2.6/kernel/user.c
@@ -362,6 +362,24 @@ static void free_user(struct user_struct
 
 #endif
 
+#if defined(CONFIG_RT_GROUP_SCHED) && defined(CONFIG_USER_SCHED)
+/*
+ * We need to check if a setuid can take place. This function should be called
+ * before successfully completing the setuid.
+ */
+int task_can_switch_user(struct user_struct *up, struct task_struct *tsk)
+{
+
+	return sched_rt_can_attach(up->tg, tsk);
+
+}
+#else
+int task_can_switch_user(struct user_struct *up, struct task_struct *tsk)
+{
+	return 1;
+}
+#endif
+
 /*
  * Locate the user_struct for the passed UID.  If found, take a ref on it.  The
  * caller must undo that ref with free_uid().
Index: linux-2.6/kernel/sys.c
===================================================================
--- linux-2.6.orig/kernel/sys.c
+++ linux-2.6/kernel/sys.c
@@ -560,7 +560,7 @@ error:
 	abort_creds(new);
 	return retval;
 }
-  
+
 /*
  * change the user struct in a credentials set to match the new UID
  */
@@ -572,6 +572,11 @@ static int set_user(struct cred *new)
 	if (!new_user)
 		return -EAGAIN;
 
+	if (!task_can_switch_user(new_user, current)) {
+		free_uid(new_user);
+		return -ENOSPC;
+	}
+
 	if (atomic_read(&new_user->processes) >=
 				current->signal->rlim[RLIMIT_NPROC].rlim_cur &&
 			new_user != INIT_USER) {
@@ -632,10 +637,11 @@ SYSCALL_DEFINE2(setreuid, uid_t, ruid, u
 			goto error;
 	}
 
-	retval = -EAGAIN;
-	if (new->uid != old->uid && set_user(new) < 0)
-		goto error;
-
+	if (new->uid != old->uid) {
+		retval = set_user(new);
+		if (retval < 0)
+			goto error;
+	}
 	if (ruid != (uid_t) -1 ||
 	    (euid != (uid_t) -1 && euid != old->uid))
 		new->suid = new->euid;
@@ -681,9 +687,10 @@ SYSCALL_DEFINE1(setuid, uid_t, uid)
 	retval = -EPERM;
 	if (capable(CAP_SETUID)) {
 		new->suid = new->uid = uid;
-		if (uid != old->uid && set_user(new) < 0) {
-			retval = -EAGAIN;
-			goto error;
+		if (uid != old->uid) {
+			retval = set_user(new);
+			if (retval < 0)
+				goto error;
 		}
 	} else if (uid != old->uid && uid != new->suid) {
 		goto error;
@@ -735,11 +742,13 @@ SYSCALL_DEFINE3(setresuid, uid_t, ruid, 
 			goto error;
 	}
 
-	retval = -EAGAIN;
 	if (ruid != (uid_t) -1) {
 		new->uid = ruid;
-		if (ruid != old->uid && set_user(new) < 0)
-			goto error;
+		if (ruid != old->uid) {
+			retval = set_user(new);
+			if (retval < 0)
+				goto error;
+		}
 	}
 	if (euid != (uid_t) -1)
 		new->euid = euid;
-- 
regards,
Dhaval

  reply	other threads:[~2009-02-17 10:16 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-02-15  0:51 RT scheduling and a way to make a process hang, unkillable Corey Hickey
2009-02-15 11:24 ` Peter Zijlstra
2009-02-16 10:36   ` Dhaval Giani
2009-02-16 11:08     ` Peter Zijlstra
2009-02-16 12:02       ` Dhaval Giani
2009-02-16 12:24         ` Peter Zijlstra
2009-02-16 13:14           ` Dhaval Giani
2009-02-16 13:19             ` Peter Zijlstra
2009-02-16 14:23               ` Peter Zijlstra
2009-02-16 13:20             ` Dhaval Giani
2009-02-16 19:18               ` Corey Hickey
2009-02-17  5:00                 ` Dhaval Giani
2009-02-17 10:15                   ` Dhaval Giani [this message]
2009-02-17 11:15                     ` Peter Zijlstra
2009-02-18  0:09                       ` Corey Hickey
2009-02-23 11:45                       ` Dhaval Giani
2009-02-23 11:59                         ` Peter Zijlstra
2009-02-24  9:18                           ` Dhaval Giani
2009-02-24 15:58                             ` Andi Kleen
2009-02-24 16:36                               ` Peter Zijlstra
2009-02-24 19:29                                 ` Chris Friesen
2009-02-27  9:43                                   ` [PATCH] sched: Don't allow setuid to succeed if the user does not have rt bandwidth Dhaval Giani
2009-02-27 10:25                                     ` Ingo Molnar
2009-02-16 20:16     ` RT scheduling and a way to make a process hang, unkillable Kyle Moffett
2009-02-16 20:28       ` Peter Zijlstra
2009-02-17  7:22       ` Dhaval Giani

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20090217101542.GB15989@linux.vnet.ibm.com \
    --to=dhaval@linux.vnet.ibm.com \
    --cc=balbir@in.ibm.com \
    --cc=bharata@linux.vnet.ibm.com \
    --cc=bugfood-ml@fatooh.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=mtk.manpages@gmail.com \
    --cc=peterz@infradead.org \
    --cc=vatsa@linux.vnet.ibm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.