Documented the currently bogus state of support for CFS user groups with
user namespaces. In particular, all users in a user namespace should be
children of the user which created the user namespace. This is yet to
be implemented.
Signed-off-by: Serge E. Hallyn <[email protected]>
Acked-by: Dhaval Giani <[email protected]>
Signed-off-by: Serge E. Hallyn <[email protected]>
---
Documentation/scheduler/sched-design-CFS.txt | 21 +++++++++++++++++++++
kernel/user.c | 8 +++++++-
2 files changed, 28 insertions(+), 1 deletions(-)
diff --git a/Documentation/scheduler/sched-design-CFS.txt b/Documentation/scheduler/sched-design-CFS.txt
index eb471c7..8398ca4 100644
--- a/Documentation/scheduler/sched-design-CFS.txt
+++ b/Documentation/scheduler/sched-design-CFS.txt
@@ -273,3 +273,24 @@ task groups and modify their CPU share using the "cgroups" pseudo filesystem.
# #Launch gmplayer (or your favourite movie player)
# echo <movie_player_pid> > multimedia/tasks
+
+8. Implementation note: user namespaces
+
+User namespaces are intended to be hierarchical. But they are currently
+only partially implemented. Each of those has ramifications for CFS.
+
+First, since user namespaces are hierarchical, the /sys/kernel/uids
+presentation is inadequate. Eventually we will likely want to use sysfs
+tagging to provide private views of /sys/kernel/uids within each user
+namespace.
+
+Second, the hierarchical nature is intended to support completely
+unprivileged use of user namespaces. So if using user groups, then
+we want the users in a user namespace to be children of the user
+who created it.
+
+That is currently unimplemented. So instead, every user in a new
+user namespace will receive 1024 shares just like any user in the
+initial user namespace. Note that at the moment creation of a new
+user namespace requires each of CAP_SYS_ADMIN, CAP_SETUID, and
+CAP_SETGID.
diff --git a/kernel/user.c b/kernel/user.c
index 6c924bc..6608a3d 100644
--- a/kernel/user.c
+++ b/kernel/user.c
@@ -239,7 +239,13 @@ static struct kobj_type uids_ktype = {
.release = uids_release,
};
-/* create /sys/kernel/uids/<uid>/cpu_share file for this user */
+/*
+ * Create /sys/kernel/uids/<uid>/cpu_share file for this user
+ * We do not create this file for users in a user namespace (until
+ * sysfs tagging is implemented).
+ *
+ * See Documentation/scheduler/sched-design-CFS.txt for ramifications.
+ */
static int uids_user_create(struct user_struct *up)
{
struct kobject *kobj = &up->kobj;
--
1.5.4.3
On Mon, 8 Dec 2008, Serge E. Hallyn wrote:
> Documented the currently bogus state of support for CFS user groups with
> user namespaces. In particular, all users in a user namespace should be
> children of the user which created the user namespace. This is yet to
> be implemented.
>
> Signed-off-by: Serge E. Hallyn <[email protected]>
> Acked-by: Dhaval Giani <[email protected]>
>
> Signed-off-by: Serge E. Hallyn <[email protected]>
Applied.
--
James Morris
<[email protected]>
Quoting James Morris ([email protected]):
> On Mon, 8 Dec 2008, Serge E. Hallyn wrote:
>
> > Documented the currently bogus state of support for CFS user groups with
> > user namespaces. In particular, all users in a user namespace should be
> > children of the user which created the user namespace. This is yet to
> > be implemented.
> >
> > Signed-off-by: Serge E. Hallyn <[email protected]>
> > Acked-by: Dhaval Giani <[email protected]>
> >
> > Signed-off-by: Serge E. Hallyn <[email protected]>
>
> Applied.
Thanks, James.
-serge
* James Morris <[email protected]> wrote:
> On Mon, 8 Dec 2008, Serge E. Hallyn wrote:
>
> > Documented the currently bogus state of support for CFS user groups with
> > user namespaces. In particular, all users in a user namespace should be
> > children of the user which created the user namespace. This is yet to
> > be implemented.
> >
> > Signed-off-by: Serge E. Hallyn <[email protected]>
> > Acked-by: Dhaval Giani <[email protected]>
> >
> > Signed-off-by: Serge E. Hallyn <[email protected]>
>
> Applied.
hm, i'd rather carry these in the scheduler tree as we've got some
changes in this area already and because these are arguably scheduler
changes:
Documentation/scheduler/sched-design-CFS.txt | 21 +++++++++++++++++++++
kernel/user.c | 8 +++++++-
the incompleteness of CONFIG_USER_SCHED is not addressed yet.
Ok?
Ingo
On Tue, 9 Dec 2008, Ingo Molnar wrote:
> hm, i'd rather carry these in the scheduler tree as we've got some
> changes in this area already and because these are arguably scheduler
> changes:
>
> Documentation/scheduler/sched-design-CFS.txt | 21 +++++++++++++++++++++
> kernel/user.c | 8 +++++++-
>
> the incompleteness of CONFIG_USER_SCHED is not addressed yet.
>
> Ok?
They're already published in my tree. Do you want me to revert them?
--
James Morris
<[email protected]>
* James Morris <[email protected]> wrote:
> On Tue, 9 Dec 2008, Ingo Molnar wrote:
>
> > hm, i'd rather carry these in the scheduler tree as we've got some
> > changes in this area already and because these are arguably scheduler
> > changes:
> >
> > Documentation/scheduler/sched-design-CFS.txt | 21 +++++++++++++++++++++
> > kernel/user.c | 8 +++++++-
> >
> > the incompleteness of CONFIG_USER_SCHED is not addressed yet.
> >
> > Ok?
>
> They're already published in my tree. Do you want me to revert them?
I've also got it published :-/ If it's at the tail of your commits, can
you reset it?
Ingo
On Tue, 9 Dec 2008, Ingo Molnar wrote:
> > They're already published in my tree. Do you want me to revert them?
>
> I've also got it published :-/ If it's at the tail of your commits, can
> you reset it?
There have been commits since, and people are using the tree in any case.
- James
--
James Morris
<[email protected]>
Quoting James Morris ([email protected]):
> On Tue, 9 Dec 2008, Ingo Molnar wrote:
>
> > > They're already published in my tree. Do you want me to revert them?
> >
> > I've also got it published :-/ If it's at the tail of your commits, can
> > you reset it?
>
> There have been commits since, and people are using the tree in any case.
Yikes. Maybe it's best (henceforth) to keep user namespaces patches in
their own tree toward the end of linux-next? There certainly are
security implications with all of them, but other things (filesystem,
sched) will be impacted as well...
Sorry.
-serge
* Serge E. Hallyn <[email protected]> wrote:
> Quoting James Morris ([email protected]):
> > On Tue, 9 Dec 2008, Ingo Molnar wrote:
> >
> > > > They're already published in my tree. Do you want me to revert them?
> > >
> > > I've also got it published :-/ If it's at the tail of your commits, can
> > > you reset it?
> >
> > There have been commits since, and people are using the tree in any case.
>
> Yikes. Maybe it's best (henceforth) to keep user namespaces patches in
> their own tree toward the end of linux-next? There certainly are
> security implications with all of them, but other things (filesystem,
> sched) will be impacted as well...
i'm fine with having this in James's tree - i didnt realize that you had
another commit that created dependencies.
(if such situations ever cause real damage then we can always create a
separate branch to track it cleanly. That's not needed now.)
Ingo