Lines Matching full:in
16 in userspace is::
20 ``u`` indicates the first element in the upper idmapset ``U`` and ``k``
21 indicates the first element in the lower idmapset ``K``. The ``r`` parameter
24 we're talking about an id in the upper or lower idmapset.
26 To see what this looks like in practice, let's take the following idmapping::
38 order isomorphic. In fact, ``U`` and ``K`` are always well-ordered subsets of
59 ``u1000`` from the upper idmapset down to ``k11000`` in the lower idmapset.
62 what id ``k11000`` corresponds to in the second or third idmapping. The
78 contain ``u1000`` in the upper idmapset ``U``. This is equivalent to not having
79 an id mapped. We can simply say that ``u1000`` is unmapped in the second and
107 Assume we are given ``k21000`` in the lower idmapset of the first idmapping. We
108 want to know what id this was mapped from in the upper idmapset of the first
109 idmapping. So we're mapping up in the first idmapping::
114 Now assume we are given the id ``u1100`` in the upper idmapset of the second
115 idmapping and we want to know what this id maps down to in the lower idmapset
116 of the second idmapping. This means we're mapping down in the second
125 In the context of the kernel an idmapping can be interpreted as mapping a range
130 A userspace id is always an element in the upper idmapset of an idmapping of
131 type ``uid_t`` or ``gid_t`` and a kernel id is always an element in the lower
137 permission checks and are stored in an inode's ``i_uid`` and ``i_gid`` field.
149 For example, the id ``u1000`` is an id in the upper idmapset or "userspace
151 kernel id in the lower idmapset or "kernel idmapset" starting with ``k10000``.
179 - If a filesystem were to be mounted in the initial user namespaces (as most
198 This translation algorithm is used by the kernel in quite a few places. For
202 If we've been given ``k11000`` from one idmapping we can map that id up in
203 another idmapping. In order for this to work both idmappings need to contain
204 the same kernel id in their kernel idmapsets. For example, consider the
210 and we are mapping ``u1000`` down to ``k11000`` in the first idmapping . We can
211 then translate ``k11000`` into a userspace id in the second idmapping using the
214 /* Map the kernel id up into a userspace id in the second idmapping. */
217 Note, how we can get back to the kernel id in the first idmapping by inverting
220 /* Map the userspace id down into a kernel id in the second idmapping. */
223 /* Map the kernel id up into a userspace id in the first idmapping. */
227 kernel id corresponds to in a given idmapping. In order to be able to answer
228 this question both idmappings need to contain the same kernel id in their
235 means ``u1000`` will be mapped to ``k21000`` which is what will be stored in
238 When someone in userspace calls ``stat()`` or a related function to get
243 So the kernel will map the id back up in the idmapping of the caller. Let's
260 and we are given ``k11000`` in the first idmapping. In order to translate this
261 kernel id in the first idmapping into a kernel id in the second idmapping we
264 1. Map the kernel id up into a userspace id in the first idmapping::
266 /* Map the kernel id up into a userspace id in the first idmapping. */
269 2. Map the userspace id down into a kernel id in the second idmapping::
271 /* Map the userspace id down into a kernel id in the second idmapping. */
274 As you can see we used the userspace idmapset in both idmappings to translate
275 the kernel id in one idmapping to a kernel id in another idmapping.
278 get the same userspace id in another idmapping. In order to be able to answer
279 this question both idmappings need to contain the same userspace id in their
282 Note, how we can easily get back to the kernel id in the first idmapping by
285 1. Map the kernel id up into a userspace id in the second idmapping::
287 /* Map the kernel id up into a userspace id in the second idmapping. */
290 2. Map the userspace id down into a kernel id in the first idmapping::
292 /* Map the userspace id down into a kernel id in the first idmapping. */
297 userspace id mapped. This will come in handy when working with idmapped mounts.
302 It is never valid to use an id in the kernel idmapset of one idmapping as the
303 id in the userspace idmapset of another or the same idmapping. While the kernel
304 idmapset always indicates an idmapset in the kernel id space the userspace
307 /* Map the userspace id down into a kernel id in the first idmapping. */
310 /* INVALID: Map the kernel id down into a kernel id in the second idmapping. */
316 /* Map the kernel id up into a userspace id in the first idmapping. */
319 /* INVALID: Map the userspace id up into a userspace id in the second idmapping. */
326 The concepts of mapping an id down or mapping an id up are expressed in the two
328 already used in this document::
341 objects in is readable and writable for everyone.
348 get lost in too many details.
352 1. Map the caller's userspace ids down into kernel ids in the caller's
354 (To be precise, the kernel will simply look at the kernel ids stashed in the
356 translation happens just in time.)
357 2. Verify that the caller's kernel ids can be mapped up to userspace ids in the
367 crossmapping algorithm we mentioned above in a previous section. First, the
383 1. Map the caller's userspace ids into kernel ids in the caller's idmapping::
387 2. Verify that the caller's kernel ids can be mapped to userspace ids in the
396 In this example both idmappings are the same so there's nothing exciting going
408 1. Map the caller's userspace ids down into kernel ids in the caller's
413 2. Verify that the caller's kernel ids can be mapped up to userspace ids in the
419 successfully mapped down into kernel ids in the caller's idmapping the kernel
424 mounted with non-initial idmappings this is a general problem as we can see in
436 1. Map the caller's userspace ids down into kernel ids in the caller's
441 2. Verify that the caller's kernel ids can be mapped up to userspace ids in the
448 the kernel id that was created in the caller's idmapping. This has mainly two
455 important in containerized workloads.
459 kernel ids map up into valid userspace ids in the caller's idmapping
461 1. Map raw userspace ids down to kernel ids in the filesystem's idmapping::
465 2. Map kernel ids up to userspace ids in the caller's idmapping::
478 In order to report ownership to userspace the kernel uses the crossmapping
479 algorithm introduced in a previous section:
481 1. Map the userspace id on disk down into a kernel id in the filesystem's
486 2. Map the kernel id up into a userspace id in the caller's idmapping::
490 The crossmapping algorithm fails in this case because the kernel id in the
491 filesystem idmapping cannot be mapped up to a userspace id in the caller's
504 In order to report ownership to userspace the kernel uses the crossmapping
505 algorithm introduced in a previous section:
507 1. Map the userspace id on disk down into a kernel id in the filesystem's
512 2. Map the kernel id up into a userspace id in the caller's idmapping::
516 Again, the crossmapping algorithm fails in this case because the kernel id in
517 the filesystem idmapping cannot be mapped to a userspace id in the caller's
521 Note how in the last two examples things would be simple if the caller would be
526 1. Map the userspace id on disk down into a kernel id in the filesystem's
531 2. Map the kernel id up into a userspace id in the caller's idmapping::
538 The examples we've seen in the previous section where the caller's idmapping
568 This would still leave ``dir`` rather useless to the second container. In fact,
576 on their machine at home and all files in their home directory will usually be
581 In both cases changing ownership recursively has grave implications. The most
582 obvious one is that ownership is changed globally and permanently. In the home
583 directory case this change in ownership would even need to happen everytime the
589 change in ownership is tied to the lifetime of the filesystem mount, i.e. the
591 filesystem and mount it again in another user namespace. This is usually
607 Idmapped mounts make it possible to change ownership in a temporary and
616 privileged users in the initial user namespace.
631 kernel ids in the mount's idmapping::
633 /* Map the filesystem's kernel id up into a userspace id in the filesystem's idmapping. */
636 /* Map the filesystem's userspace id down ito a kernel id in the mount's idmapping. */
642 kernel ids in the filesystem's idmapping. This translation is achieved by
645 /* Map the caller's kernel id up into a userspace id in the mount's idmapping. */
648 /* Map the mount's userspace id down into a kernel id in the filesystem's idmapping. */
659 to ``k21000`` according to it's idmapping. This is what is stored in the
664 kernel id up to a userspace id in the caller's idmapping.
668 into a kernel id in the mount's idmapping::
674 /* Map the filesystem's userspace id down ito a kernel id in the mount's idmapping. */
678 kernel id in the mount's idmapping into a userspace id in the caller's
686 The kernel maps this to ``k11000`` in the caller's idmapping. Usually the
688 mapped to a userspace id in the filesystem's idmapping. Since ``k11000`` can't
689 be mapped up in the filesystem's idmapping directly this creation request
697 /* Map the caller's kernel id up into a userspace id in the mount's idmapping. */
700 /* Map the mount's userspace id down into a kernel id in the filesystem's idmapping. */
704 userspace id in the filesystem's idmapping::
712 Let's now briefly reconsider the failing examples from earlier in the context
728 1. Map the caller's userspace ids into kernel ids in the caller's idmapping::
732 2. Translate the caller's kernel id into a kernel id in the filesystem's
736 /* Map the kernel id up into a userspace id in the mount's idmapping. */
739 /* Map the userspace id down into a kernel id in the filesystem's idmapping. */
742 2. Verify that the caller's kernel ids can be mapped to userspace ids in the
761 1. Map the caller's userspace ids into kernel ids in the caller's idmapping::
765 2. Translate the caller's kernel id into a kernel id in the filesystem's
769 /* Map the kernel id up into a userspace id in the mount's idmapping. */
772 /* Map the userspace id down into a kernel id in the filesystem's idmapping. */
775 2. Verify that the caller's kernel ids can be mapped to userspace ids in the
792 In order to report ownership to userspace the kernel now does three steps using
795 1. Map the userspace id on disk down into a kernel id in the filesystem's
800 2. Translate the kernel id into a kernel id in the mount's idmapping::
803 /* Map the kernel id up into a userspace id in the filesystem's idmapping. */
806 /* Map the userspace id down into a kernel id in the mounts's idmapping. */
809 3. Map the kernel id up into a userspace id in the caller's idmapping::
813 Earlier, the caller's kernel id couldn't be crossmapped in the filesystems's
814 idmapping. With the idmapped mount in place it now can be crossmapped into the
828 Again, in order to report ownership to userspace the kernel now does three
831 1. Map the userspace id on disk down into a kernel id in the filesystem's
836 2. Translate the kernel id into a kernel id in the mount's idmapping::
839 /* Map the kernel id up into a userspace id in the filesystem's idmapping. */
842 /* Map the userspace id down into a kernel id in the mounts's idmapping. */
845 3. Map the kernel id up into a userspace id in the caller's idmapping::
849 Earlier, the file's kernel id couldn't be crossmapped in the filesystems's
850 idmapping. With the idmapped mount in place it now can be crossmapped into the
860 a non-initial idmapping. This mostly happens in the context of containerized
875 storage. At home they have id ``u1000`` and all files in their home directory
889 plugs in their portable storage at their work station they can setup a job that
899 1. Map the caller's userspace ids into kernel ids in the caller's idmapping::
903 2. Translate the caller's kernel id into a kernel id in the filesystem's
907 /* Map the kernel id up into a userspace id in the mount's idmapping. */
910 /* Map the userspace id down into a kernel id in the filesystem's idmapping. */
913 2. Verify that the caller's kernel ids can be mapped to userspace ids in the
930 1. Map the userspace id on disk down into a kernel id in the filesystem's
935 2. Translate the kernel id into a kernel id in the mount's idmapping::
938 /* Map the kernel id up into a userspace id in the filesystem's idmapping. */
941 /* Map the userspace id down into a kernel id in the mounts's idmapping. */
944 3. Map the kernel id up into a userspace id in the caller's idmapping::
949 which is the caller's userspace id on their workstation in our example.
969 1. We always stash a reference to the initial user namespace in ``struct
973 In order to support idmapped mounts this needs to be changed. Instead of
979 2. The translation algorithms in ``mapped_fs*id()`` and ``i_*id_into_mnt()``
983 caller's kernel id into a kernel id in the filesystem's idmapping via
987 /* Map the kernel id up into a userspace id in the mount's idmapping. */
990 /* Map the userspace id down into a kernel id in the filesystem's idmapping. */
994 we enforce this in ``mount_setattr()``. So this can be shortened to::
997 /* Map the kernel id up into a userspace id in the mount's idmapping. */
1000 /* Map the userspace id down into a kernel id in the filesystem's idmapping. */
1007 /* Map the kernel id up into a userspace id in the filesystem's idmapping. */
1010 /* Map the userspace id down into a kernel id in the mounts's idmapping. */
1014 idmapping as we enforce this in ``mount_setattr()``. So this can be
1018 /* Map the kernel id up into a userspace id in the filesystem's idmapping. */
1021 /* Map the userspace id down into a kernel id in the mounts's idmapping. */