Lines Matching refs:caller
241 the caller is using an idmapping.
243 So the kernel will map the id back up in the idmapping of the caller. Let's
244 assume the caller has the slighly unconventional idmapping
343 When creating a filesystem object the caller will look at the caller's
347 the caller but can differ. We will just assume they are always identical to not
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
357 2. Verify that the caller's kernel ids can be mapped up to userspace ids in the
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
372 Let's see some examples with caller/filesystem idmapping but without mount
382 caller id: u1000
383 caller idmapping: u0:k0:r4294967295
386 Both the caller and the filesystem use the identity idmapping:
388 1. Map the caller's userspace ids into kernel ids in the caller's idmapping::
392 2. Verify that the caller's kernel ids can be mapped to userspace ids in the
409 caller id: u1000
410 caller idmapping: u0:k10000:r10000
413 1. Map the caller's userspace ids down into kernel ids in the caller's
418 2. Verify that the caller's kernel ids can be mapped up to userspace ids in the
423 It's immediately clear that while the caller's userspace id could be
424 successfully mapped down into kernel ids in the caller's idmapping the kernel
437 caller id: u1000
438 caller idmapping: u0:k10000:r10000
441 1. Map the caller's userspace ids down into kernel ids in the caller's
446 2. Verify that the caller's kernel ids can be mapped up to userspace ids in the
453 the kernel id that was created in the caller's idmapping. This has mainly two
456 First, that we can't allow a caller to ultimately write to disk with another
458 with the caller's or another idmapping. But that solution is limited to a few
462 Second, the caller will usually not be able to create any files or access
464 kernel ids map up into valid userspace ids in the caller's idmapping
470 2. Map kernel ids up to userspace ids in the caller's idmapping::
480 caller idmapping: u0:k10000:r10000
491 2. Map the kernel id up into a userspace id in the caller's idmapping::
496 filesystem idmapping cannot be mapped up to a userspace id in the caller's
506 caller idmapping: u0:k10000:r10000
517 2. Map the kernel id up into a userspace id in the caller's idmapping::
522 the filesystem idmapping cannot be mapped to a userspace id in the caller's
526 Note how in the last two examples things would be simple if the caller would be
536 2. Map the kernel id up into a userspace id in the caller's idmapping::
543 The examples we've seen in the previous section where the caller's idmapping
609 is then used to translate from the caller's idmapping to the filesystem's
646 The ``mapped_fs*id()`` functions translate the caller's kernel ids into
648 remapping the caller's kernel ids using the mount's idmapping::
650 /* Map the caller's kernel id up into a userspace id in the mount's idmapping. */
659 caller idmapping: u0:k10000:r10000
667 When the caller queries the ownership of this file via ``stat()`` the kernel
669 kernel id up to a userspace id in the caller's idmapping.
671 But when the caller is accessing the file on an idmapped mount the kernel will
682 Finally, when the kernel reports the owner to the caller it will turn the
683 kernel id in the mount's idmapping into a userspace id in the caller's
691 The kernel maps this to ``k11000`` in the caller's idmapping. Usually the
697 But when the caller is accessing the file on an idmapped mount the kernel will
698 first call ``mapped_fs*id()`` thereby translating the caller's kernel id into
702 /* Map the caller's kernel id up into a userspace id in the mount's idmapping. */
725 caller id: u1000
726 caller idmapping: u0:k10000:r10000
730 When the caller is using a non-initial idmapping the common case is to attach
733 1. Map the caller's userspace ids into kernel ids in the caller's idmapping::
737 2. Translate the caller's kernel id into a kernel id in the filesystem's
747 2. Verify that the caller's kernel ids can be mapped to userspace ids in the
759 caller id: u1000
760 caller idmapping: u0:k10000:r10000
766 1. Map the caller's userspace ids into kernel ids in the caller's idmapping::
770 2. Translate the caller's kernel id into a kernel id in the filesystem's
780 2. Verify that the caller's kernel ids can be mapped to userspace ids in the
793 caller idmapping: u0:k10000:r10000
814 3. Map the kernel id up into a userspace id in the caller's idmapping::
818 Earlier, the caller's kernel id couldn't be crossmapped in the filesystems's
829 caller idmapping: u0:k10000:r10000
850 3. Map the kernel id up into a userspace id in the caller's idmapping::
863 idmappings when either the caller, the filesystem or both uses a non-initial
864 idmapping. A wide range of usecases exist when the caller is using
869 be crossmapped between the caller's and the filesystem's idmapping.
872 caller's or filesystem's idmapping according to the mount's idmapping.
875 they also work when both the caller and the filesystem use the initial
899 caller id: u1125
900 caller idmapping: u0:k0:r4294967295
904 1. Map the caller's userspace ids into kernel ids in the caller's idmapping::
908 2. Translate the caller's kernel id into a kernel id in the filesystem's
918 2. Verify that the caller's kernel ids can be mapped to userspace ids in the
925 Now let's briefly look at what ownership the caller with id ``u1125`` will see
931 caller idmapping: u0:k0:r4294967295
949 3. Map the kernel id up into a userspace id in the caller's idmapping::
953 So ultimately the caller will be reported that the file belongs to ``u1125``
954 which is the caller's userspace id on their workstation in our example.