Lines Matching +full:two +full:- +full:user
1 .. SPDX-License-Identifier: GPL-2.0
12 ------------
32 u22 -> k10000
33 u23 -> k10001
34 u24 -> k10002
36 From a mathematical viewpoint ``U`` and ``K`` are well-ordered sets and an
38 order isomorphic. In fact, ``U`` and ``K`` are always well-ordered subsets of
45 k10000 -> u22
46 k10001 -> u23
47 k10002 -> u24
81 ``(uid_t)-1`` or overflowgid ``(gid_t)-1`` to userspace.
88 - If we want to map from left to right::
91 id - u + k = n
93 - If we want to map from right to left::
96 id - k + u = n
101 To see whether the simple formulas above work, consider the following two
111 id - k + u = n
112 k21000 - k20000 + u0 = u1000
119 id - u + k = n
120 u1100 - u500 + k30000 = k30600
123 -------------
128 userspace-id:kernel-id:range
155 with user namespaces. Since we mainly care about how idmappings work we're not
157 outside of the filesystem context. This is best left to an explanation of user
160 The initial user namespace is special. It always has an idmapping of the
168 Other user namespaces usually have non-identity idmappings such as::
175 with the relevant user namespace.
180 - If a filesystem were to be mounted in the initial user namespaces (as most
186 - If a filesystem were to be mounted with an idmapping of ``u0:k10000:r10000``
191 ----------------------
247 Consequently the user would see that this file is owned by ``u4000``.
253 the userspace idmapset of the two idmappings. This is equivalent to remapping
256 Let's look at an example. We are given the following two idmappings::
263 need to perform two steps:
326 conflated. So the two examples above would cause a compilation failure.
329 -------------------------------------------
331 The concepts of mapping an id down or mapping an id up are expressed in the two
355 When the caller enters the kernel two things happen:
378 All idmappings are taken from the corresponding user namespace.
380 - caller's idmapping (usually taken from ``current_user_ns()``)
381 - filesystem's idmapping (``sb->s_user_ns``)
382 - mount's idmapping (``mnt_idmap(vfsmnt)``)
433 from_kuid(u0:k20000:r10000, k11000) = u-1
441 mounted with non-initial idmappings this is a general problem as we can see in
465 the kernel id that was created in the caller's idmapping. This has mainly two
471 filesystems and not very flexible. But this is a use-case that is pretty
484 from_kuid(u0:k10000:r10000, k1000) = u-1
505 from_kuid(u0:k10000:r10000, k1000) = u-1
531 from_kuid(u0:k10000:r10000, k21000) = u-1
538 Note how in the last two examples things would be simple if the caller would be
553 -----------------------------
557 workloads. For a more complex but common example, consider two containers
558 started on the host. To completely prevent the two containers from affecting
559 each other, an administrator may often use different non-overlapping idmappings
560 for the two containers::
566 An administrator wanting to provide easy read-write access to the following set
590 systemd implement a concept called "portable home directories". A user may want
601 user switches from their home to their work machine. For really large sets of
604 If the user is lucky, they are dealing with a filesystem that is mountable
605 inside user namespaces. But this would also change ownership globally and the
608 filesystem and mount it again in another user namespace. This is usually
611 between two containers with different idmappings.
612 But usually the user doesn't even have this option since most filesystems
619 different mounts. This is achieved by marking the mounts with a user namespace
630 being mountable inside user namespaces. A filesystem could be exposed
633 privileged users in the initial user namespace.
636 mountable inside user namespaces. We will touch on this further below.
662 uid_t <--> kuid_t <--> vfsuid_t
663 gid_t <--> kgid_t <--> vfsgid_t
704 - ``i_uid_into_vfsuid()`` and ``i_gid_into_vfsgid()``
715 - ``mapped_fsuid()`` and ``mapped_fsgid()``
727 - ``vfsuid_into_kuid()`` and ``vfsgid_into_kgid()``
731 Note that these two functions invert each other. Consider the following
765 we create a new file. Let's say the user is creating a file with ``u1000``.
807 When the caller is using a non-initial idmapping the common case is to attach
942 idmappings when either the caller, the filesystem or both uses a non-initial
944 a non-initial idmapping. This mostly happens in the context of containerized
946 mounted with the initial idmapping and filesystems mounted with non-initial
956 and files on a per-mount basis.
958 Consider our previous example where a user has their home directory on portable
967 Idmapped mounts allow to solve this problem. A user can create an idmapped
972 Let's assume they want all files on disk to belong to ``u1000``. When the user
1036 The raw userspace id that is put on disk is ``u1000`` so when the user takes