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 ``k11000`` which is a kernel id in the lower idmapset or "kernel idmapset"
154 A kernel id is always created by an idmapping. Such idmappings are associated
174 immediately translated into a kernel id according to the idmapping associated
199 This translation algorithm is used by the kernel in quite a few places. For
205 the same kernel id in their kernel idmapsets. For example, consider the
213 kernel idmapset of the second idmapping::
215 /* Map the kernel id up into a userspace id in the second idmapping. */
218 Note, how we can get back to the kernel id in the first idmapping by inverting
221 /* Map the userspace id down into a kernel id in the second idmapping. */
224 /* Map the kernel id up into a userspace id in the first idmapping. */
228 kernel id corresponds to in a given idmapping. In order to be able to answer
229 this question both idmappings need to contain the same kernel id in their
230 respective kernel idmapsets.
232 For example, when the kernel reads a raw userspace id from disk it maps it down
233 into a kernel id according to the idmapping associated with the filesystem.
240 ownership information about the file the kernel can't simply map the id back up
244 So the kernel will map the id back up in the idmapping of the caller. Let's
252 It is possible to translate a kernel id from one idmapping to another one via
254 a kernel id.
262 kernel id in the first idmapping into a kernel id in the second idmapping we
265 1. Map the kernel id up into a userspace id in the first idmapping::
267 /* Map the kernel id up into a userspace id in the first idmapping. */
270 2. Map the userspace id down into a kernel id in the second idmapping::
272 /* Map the userspace id down into a kernel id in the second idmapping. */
276 the kernel id in one idmapping to a kernel id in another idmapping.
278 This allows us to answer the question what kernel id we would need to use to
283 Note, how we can easily get back to the kernel id in the first idmapping by
286 1. Map the kernel id up into a userspace id in the second idmapping::
288 /* Map the kernel id up into a userspace id in the second idmapping. */
291 2. Map the userspace id down into a kernel id in the first idmapping::
293 /* Map the userspace id down into a kernel id in the first idmapping. */
303 It is never valid to use an id in the kernel idmapset of one idmapping as the
304 id in the userspace idmapset of another or the same idmapping. While the kernel
305 idmapset always indicates an idmapset in the kernel id space the userspace
308 /* Map the userspace id down into a kernel id in the first idmapping. */
311 /* INVALID: Map the kernel id down into a kernel id in the second idmapping. */
317 /* Map the kernel id up into a userspace id in the first idmapping. */
324 Since userspace ids have type ``uid_t`` and ``gid_t`` and kernel ids have type
332 kernel functions filesystem developers are rather familiar with and which we've
335 /* Map the userspace id down into a kernel id. */
338 /* Map the kernel id up into a userspace id. */
355 When the caller enters the kernel two things happen:
357 1. Map the caller's userspace ids down into kernel ids in the caller's
359 (To be precise, the kernel will simply look at the kernel ids stashed in the
362 2. Verify that the caller's kernel ids can be mapped up to userspace ids in the
366 the kernel id back up into a userspace id when writing to disk.
367 So with the second step the kernel guarantees that a valid userspace id can be
368 written to disk. If it can't the kernel will refuse the creation request to not
373 kernel maps the caller's userspace id down into a kernel id according to the
374 caller's idmapping and then maps that kernel id up according to the
400 1. Map the caller's userspace ids into kernel ids in the caller's idmapping::
404 2. Verify that the caller's kernel ids can be mapped to userspace ids in the
407 For this second step the kernel will call the function
425 1. Map the caller's userspace ids down into kernel ids in the caller's
430 2. Verify that the caller's kernel ids can be mapped up to userspace ids in the
436 successfully mapped down into kernel ids in the caller's idmapping the kernel
438 kernel will deny this creation request.
453 1. Map the caller's userspace ids down into kernel ids in the caller's
458 2. Verify that the caller's kernel ids can be mapped up to userspace ids in the
465 the kernel id that was created in the caller's idmapping. This has mainly two
476 kernel ids map up into valid userspace ids in the caller's idmapping
478 1. Map raw userspace ids down to kernel ids in the filesystem's idmapping::
482 2. Map kernel ids up to userspace ids in the caller's idmapping::
495 In order to report ownership to userspace the kernel uses the crossmapping
498 1. Map the userspace id on disk down into a kernel id in the filesystem's
503 2. Map the kernel id up into a userspace id in the caller's idmapping::
507 The crossmapping algorithm fails in this case because the kernel id in the
509 idmapping. Thus, the kernel will report the ownership of this file as the
521 In order to report ownership to userspace the kernel uses the crossmapping
524 1. Map the userspace id on disk down into a kernel id in the filesystem's
529 2. Map the kernel id up into a userspace id in the caller's idmapping::
533 Again, the crossmapping algorithm fails in this case because the kernel id in
535 idmapping. Thus, the kernel will report the ownership of this file as the
543 1. Map the userspace id on disk down into a kernel id in the filesystem's
548 2. Map the kernel id up into a userspace id in the caller's idmapping::
695 kernel ids with ``k`` we will prefix all VFS ids with ``v``. So a mount
706 The ``i_*id_into_vfs*id()`` functions translate filesystem's kernel ids into
709 /* Map the filesystem's kernel id up into a userspace id in the filesystem's idmapping. */
717 The ``mapped_fs*id()`` functions translate the caller's kernel ids into
718 kernel ids in the filesystem's idmapping. This translation is achieved by
724 /* Map the mount's userspace id down into a kernel id in the filesystem's idmapping. */
742 When the caller queries the ownership of this file via ``stat()`` the kernel
744 kernel id up to a userspace id in the caller's idmapping.
746 But when the caller is accessing the file on an idmapped mount the kernel will
747 first call ``i_uid_into_vfsuid()`` thereby translating the filesystem's kernel
751 /* Map the filesystem's kernel id up into a userspace id. */
757 Finally, when the kernel reports the owner to the caller it will turn the
767 The kernel maps this to ``k11000`` in the caller's idmapping. Usually the
768 kernel would now apply the crossmapping, verifying that ``k11000`` can be
773 But when the caller is accessing the file on an idmapped mount the kernel will
774 first call ``mapped_fs*id()`` thereby translating the caller's kernel id into
778 /* Map the caller's kernel id up into a userspace id in the mount's idmapping. */
781 /* Map the mount's userspace id down into a kernel id in the filesystem's idmapping. */
784 When finally writing to disk the kernel will then map ``v21000`` up into a
810 1. Map the caller's userspace ids into kernel ids in the caller's idmapping::
814 2. Translate the caller's VFS id into a kernel id in the filesystem's
821 /* Map the userspace id down into a kernel id in the filesystem's idmapping. */
824 3. Verify that the caller's kernel ids can be mapped to userspace ids in the
843 1. Map the caller's userspace ids into kernel ids in the caller's idmapping::
847 2. Translate the caller's VFS id into a kernel id in the filesystem's
854 /* Map the userspace id down into a kernel id in the filesystem's idmapping. */
857 3. Verify that the caller's kernel ids can be mapped to userspace ids in the
874 In order to report ownership to userspace the kernel now does three steps using
877 1. Map the userspace id on disk down into a kernel id in the filesystem's
882 2. Translate the kernel id into a VFS id in the mount's idmapping::
885 /* Map the kernel id up into a userspace id in the filesystem's idmapping. */
896 Earlier, the caller's kernel id couldn't be crossmapped in the filesystems's
911 Again, in order to report ownership to userspace the kernel now does three
914 1. Map the userspace id on disk down into a kernel id in the filesystem's
919 2. Translate the kernel id into a VFS id in the mount's idmapping::
922 /* Map the kernel id up into a userspace id in the filesystem's idmapping. */
933 Earlier, the file's kernel id couldn't be crossmapped in the filesystems's
947 idmappings, access to the filesystem isn't working because the kernel ids can't
975 when they create a file the kernel performs the following steps we already know
983 1. Map the caller's userspace ids into kernel ids in the caller's idmapping::
987 2. Translate the caller's VFS id into a kernel id in the filesystem's
994 /* Map the userspace id down into a kernel id in the filesystem's idmapping. */
1014 1. Map the userspace id on disk down into a kernel id in the filesystem's
1019 2. Translate the kernel id into a VFS id in the mount's idmapping::
1022 /* Map the kernel id up into a userspace id in the filesystem's idmapping. */