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
154 with user namespaces. Since we mainly care about how idmappings work we're not
156 outside of the filesystem context. This is best left to an explanation of user
159 The initial user namespace is special. It always has an idmapping of the
167 Other user namespaces usually have non-identity idmappings such as::
174 with the relevant user namespace.
179 - If a filesystem were to be mounted in the initial user namespaces (as most
185 - If a filesystem were to be mounted with an idmapping of ``u0:k10000:r10000``
190 ----------------------
246 Consequently the user would see that this file is owned by ``u4000``.
252 the userspace idmapset of the two idmappings. This is equivalent to remapping
255 Let's look at an example. We are given the following two idmappings::
262 need to perform two steps:
324 -------------------------------------------
326 The concepts of mapping an id down or mapping an id up are expressed in the two
350 When the caller enters the kernel two things happen:
416 from_kuid(u0:k20000:r10000, k11000) = u-1
424 mounted with non-initial idmappings this is a general problem as we can see in
448 the kernel id that was created in the caller's idmapping. This has mainly two
454 filesystems and not very flexible. But this is a use-case that is pretty
467 from_kuid(u0:k10000:r10000, k1000) = u-1
488 from_kuid(u0:k10000:r10000, k1000) = u-1
514 from_kuid(u0:k10000:r10000, k21000) = u-1
521 Note how in the last two examples things would be simple if the caller would be
536 -----------------------------
540 workloads. For a more complex but common example, consider two containers
541 started on the host. To completely prevent the two containers from affecting
542 each other, an administrator may often use different non-overlapping idmappings
543 for the two containers::
549 An administrator wanting to provide easy read-write access to the following set
573 systemd implement a concept called "portable home directories". A user may want
584 user switches from their home to their work machine. For really large sets of
587 If the user is lucky, they are dealing with a filesystem that is mountable
588 inside user namespaces. But this would also change ownership globally and the
591 filesystem and mount it again in another user namespace. This is usually
594 between two containers with different idmappings.
595 But usually the user doesn't even have this option since most filesystems
602 different mounts. This is achieved by marking the mounts with a user namespace
613 being mountable inside user namespaces. A filesystem could be exposed
616 privileged users in the initial user namespace.
619 mountable inside user namespaces. We will touch on this further below.
626 two:
628 - ``i_uid_into_mnt()`` and ``i_gid_into_mnt()``
639 - ``mapped_fsuid()`` and ``mapped_fsgid()``
651 Note that these two functions invert each other. Consider the following
684 we create a new file. Let's say the user is creating a file with ``u1000``.
725 When the caller is using a non-initial idmapping the common case is to attach
858 idmappings when either the caller, the filesystem or both uses a non-initial
860 a non-initial idmapping. This mostly happens in the context of containerized
862 mounted with the initial idmapping and filesystems mounted with non-initial
872 and files on a per-mount basis.
874 Consider our previous example where a user has their home directory on portable
883 Idmapped mounts allow to solve this problem. A user can create an idmapped
888 Let's assume they want all files on disk to belong to ``u1000``. When the user
951 The raw userspace id that is put on disk is ``u1000`` so when the user takes
957 --------------
961 filesystems that we targeted were mountable with a non-initial idmapping. But
964 idmapping and filesystem with non-initial idmappings.
967 idmapping two noticeable shortcuts have been taken:
969 1. We always stash a reference to the initial user namespace in ``struct
970 vfsmount``. Idmapped mounts are thus mounts that have a non-initial user
974 stashing the initial user namespace the user namespace the filesystem was
976 a different user namespace attached then the filesystem was mounted with.
977 This has no user-visible consequences.
988 from_kuid(mount-idmapping, kid) = uid
991 make_kuid(filesystem-idmapping, uid) = kuid
998 from_kuid(mount-idmapping, kid) = uid
1008 from_kuid(filesystem-idmapping, kid) = uid
1011 make_kuid(mount-idmapping, uid) = kuid
1022 make_kuid(mount-idmapping, uid) = kuid
1024 Handling filesystems mounted with non-initial idmappings requires that the
1026 shortcircuited on non-idmapped mounts. This has no user-visible consequences.