Lines Matching full:kernel
80 third idmapping. The kernel will report unmapped ids as the overflowuid
125 In the context of the kernel an idmapping can be interpreted as mapping a range
126 of userspace ids into a range of kernel ids::
128 userspace-id:kernel-id:range
131 type ``uid_t`` or ``gid_t`` and a kernel id is always an element in the lower
134 types and "kernel id" will be used to refer to ``kuid_t`` and ``kgid_t``.
136 The kernel is mostly concerned with kernel ids. They are used when performing
139 kernel, or is passed by userspace to the kernel, or a raw device id that is
142 Note that we are only concerned with idmappings as the kernel stores them not
146 all kernel ids with ``k``. Ranges of idmappings will be prefixed with ``r``. So
151 kernel id in the lower idmapset or "kernel idmapset" starting with ``k10000``.
153 A kernel id is always created by an idmapping. Such idmappings are associated
173 immediately translated into a kernel id according to the idmapping associated
198 This translation algorithm is used by the kernel in quite a few places. For
204 the same kernel id in their kernel idmapsets. For example, consider the
212 kernel idmapset of the second idmapping::
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
229 respective kernel idmapsets.
231 For example, when the kernel reads a raw userspace id from disk it maps it down
232 into a kernel id according to the idmapping associated with the filesystem.
239 ownership information about the file the kernel can't simply map the id back up
243 So the kernel will map the id back up in the idmapping of the caller. Let's
251 It is possible to translate a kernel id from one idmapping to another one via
253 a kernel id.
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. */
275 the kernel id in one idmapping to a kernel id in another idmapping.
277 This allows us to answer the question what kernel id we would need to use to
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. */
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. */
327 kernel functions filesystem developers are rather familiar with and which we've
330 /* Map the userspace id down into a kernel id. */
333 /* Map the kernel id up into a userspace id. */
350 When the caller enters the kernel two things happen:
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
357 2. Verify that the caller's kernel ids can be mapped up to userspace ids in the
361 the kernel id back up into a userspace id when writing to disk.
362 So with the second step the kernel guarantees that a valid userspace id can be
363 written to disk. If it can't the kernel will refuse the creation request to not
368 kernel maps the caller's userspace id down into a kernel id according to the
369 caller's idmapping and then maps that kernel id up according to 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
390 For this second step the kernel will call the function
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
421 kernel will deny this creation request.
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
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
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
492 idmapping. Thus, the kernel will report the ownership of this file as the
504 In order to report ownership to userspace the kernel uses the crossmapping
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
518 idmapping. Thus, the kernel will report the ownership of this file as the
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::
630 The ``i_*id_into_mnt()`` functions translate filesystem's kernel ids into
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. */
641 The ``mapped_fs*id()`` functions translate the caller's kernel ids into
642 kernel ids in the filesystem's idmapping. This translation is achieved by
643 remapping the caller's kernel ids using the mount's idmapping::
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. */
662 When the caller queries the ownership of this file via ``stat()`` the kernel
664 kernel id up to a userspace id in the caller's idmapping.
666 But when the caller is accessing the file on an idmapped mount the kernel will
667 first call ``i_uid_into_mnt()`` thereby translating the filesystem's kernel id
668 into a kernel id in the mount's idmapping::
671 /* Map the filesystem's kernel id up into a userspace id. */
674 /* Map the filesystem's userspace id down ito a kernel id in the mount's idmapping. */
677 Finally, when the kernel reports the owner to the caller it will turn the
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
687 kernel would now apply the crossmapping, verifying that ``k11000`` can be
692 But when the caller is accessing the file on an idmapped mount the kernel will
693 first call ``mapped_fs*id()`` thereby translating the caller's kernel id into
694 a kernel id according to the mount's idmapping::
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. */
703 When finally writing to disk the kernel will then map ``k21000`` up into a
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
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
863 idmappings, access to the filesystem isn't working because the kernel ids can't
891 when they create a file the kernel performs the following steps we already know
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::
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. */
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. */
1003 Similarly, for ``i_*id_into_mnt()`` which translated the filesystem's kernel
1004 id into a mount's kernel id::
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. */
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. */