From: Mauro Carvalho Chehab Date: Tue, 18 Jun 2019 19:33:50 +0000 (-0300) Subject: docs: namespace: move it to the admin-guide X-Git-Tag: microblaze-v5.4-rc1~276^2~37 X-Git-Url: http://git.monstr.eu/?a=commitdiff_plain;h=bf6b7a742e3f82b3132e149fb17761e84207f9f1;p=linux-2.6-microblaze.git docs: namespace: move it to the admin-guide As stated at the documentation, this is meant to be for users to better understand namespaces. Signed-off-by: Mauro Carvalho Chehab --- diff --git a/Documentation/admin-guide/index.rst b/Documentation/admin-guide/index.rst index f40c4b5a181b..abc2c4e83939 100644 --- a/Documentation/admin-guide/index.rst +++ b/Documentation/admin-guide/index.rst @@ -77,6 +77,7 @@ configure specific aspects of kernel behavior to your liking. thunderbolt LSM/index mm/index + namespaces/index perf-security acpi/index diff --git a/Documentation/admin-guide/namespaces/compatibility-list.rst b/Documentation/admin-guide/namespaces/compatibility-list.rst new file mode 100644 index 000000000000..318800b2a943 --- /dev/null +++ b/Documentation/admin-guide/namespaces/compatibility-list.rst @@ -0,0 +1,43 @@ +============================= +Namespaces compatibility list +============================= + +This document contains the information about the problems user +may have when creating tasks living in different namespaces. + +Here's the summary. This matrix shows the known problems, that +occur when tasks share some namespace (the columns) while living +in different other namespaces (the rows): + +==== === === === === ==== === +- UTS IPC VFS PID User Net +==== === === === === ==== === +UTS X +IPC X 1 +VFS X +PID 1 1 X +User 2 2 X +Net X +==== === === === === ==== === + +1. Both the IPC and the PID namespaces provide IDs to address + object inside the kernel. E.g. semaphore with IPCID or + process group with pid. + + In both cases, tasks shouldn't try exposing this ID to some + other task living in a different namespace via a shared filesystem + or IPC shmem/message. The fact is that this ID is only valid + within the namespace it was obtained in and may refer to some + other object in another namespace. + +2. Intentionally, two equal user IDs in different user namespaces + should not be equal from the VFS point of view. In other + words, user 10 in one user namespace shouldn't have the same + access permissions to files, belonging to user 10 in another + namespace. + + The same is true for the IPC namespaces being shared - two users + from different user namespaces should not access the same IPC objects + even having equal UIDs. + + But currently this is not so. diff --git a/Documentation/admin-guide/namespaces/index.rst b/Documentation/admin-guide/namespaces/index.rst new file mode 100644 index 000000000000..713ec4949fa7 --- /dev/null +++ b/Documentation/admin-guide/namespaces/index.rst @@ -0,0 +1,9 @@ +========== +Namespaces +========== + +.. toctree:: + :maxdepth: 1 + + compatibility-list + resource-control diff --git a/Documentation/admin-guide/namespaces/resource-control.rst b/Documentation/admin-guide/namespaces/resource-control.rst new file mode 100644 index 000000000000..369556e00f0c --- /dev/null +++ b/Documentation/admin-guide/namespaces/resource-control.rst @@ -0,0 +1,18 @@ +=========================== +Namespaces research control +=========================== + +There are a lot of kinds of objects in the kernel that don't have +individual limits or that have limits that are ineffective when a set +of processes is allowed to switch user ids. With user namespaces +enabled in a kernel for people who don't trust their users or their +users programs to play nice this problems becomes more acute. + +Therefore it is recommended that memory control groups be enabled in +kernels that enable user namespaces, and it is further recommended +that userspace configure memory control groups to limit how much +memory user's they don't trust to play nice can use. + +Memory control groups can be configured by installing the libcgroup +package present on most distros editing /etc/cgrules.conf, +/etc/cgconfig.conf and setting up libpam-cgroup. diff --git a/Documentation/namespaces/compatibility-list.rst b/Documentation/namespaces/compatibility-list.rst deleted file mode 100644 index 318800b2a943..000000000000 --- a/Documentation/namespaces/compatibility-list.rst +++ /dev/null @@ -1,43 +0,0 @@ -============================= -Namespaces compatibility list -============================= - -This document contains the information about the problems user -may have when creating tasks living in different namespaces. - -Here's the summary. This matrix shows the known problems, that -occur when tasks share some namespace (the columns) while living -in different other namespaces (the rows): - -==== === === === === ==== === -- UTS IPC VFS PID User Net -==== === === === === ==== === -UTS X -IPC X 1 -VFS X -PID 1 1 X -User 2 2 X -Net X -==== === === === === ==== === - -1. Both the IPC and the PID namespaces provide IDs to address - object inside the kernel. E.g. semaphore with IPCID or - process group with pid. - - In both cases, tasks shouldn't try exposing this ID to some - other task living in a different namespace via a shared filesystem - or IPC shmem/message. The fact is that this ID is only valid - within the namespace it was obtained in and may refer to some - other object in another namespace. - -2. Intentionally, two equal user IDs in different user namespaces - should not be equal from the VFS point of view. In other - words, user 10 in one user namespace shouldn't have the same - access permissions to files, belonging to user 10 in another - namespace. - - The same is true for the IPC namespaces being shared - two users - from different user namespaces should not access the same IPC objects - even having equal UIDs. - - But currently this is not so. diff --git a/Documentation/namespaces/index.rst b/Documentation/namespaces/index.rst deleted file mode 100644 index bf40625dd11a..000000000000 --- a/Documentation/namespaces/index.rst +++ /dev/null @@ -1,11 +0,0 @@ -:orphan: - -========== -Namespaces -========== - -.. toctree:: - :maxdepth: 1 - - compatibility-list - resource-control diff --git a/Documentation/namespaces/resource-control.rst b/Documentation/namespaces/resource-control.rst deleted file mode 100644 index 369556e00f0c..000000000000 --- a/Documentation/namespaces/resource-control.rst +++ /dev/null @@ -1,18 +0,0 @@ -=========================== -Namespaces research control -=========================== - -There are a lot of kinds of objects in the kernel that don't have -individual limits or that have limits that are ineffective when a set -of processes is allowed to switch user ids. With user namespaces -enabled in a kernel for people who don't trust their users or their -users programs to play nice this problems becomes more acute. - -Therefore it is recommended that memory control groups be enabled in -kernels that enable user namespaces, and it is further recommended -that userspace configure memory control groups to limit how much -memory user's they don't trust to play nice can use. - -Memory control groups can be configured by installing the libcgroup -package present on most distros editing /etc/cgrules.conf, -/etc/cgconfig.conf and setting up libpam-cgroup.