Lines Matching refs:caller
242 the caller is using an idmapping.
244 So the kernel will map the id back up in the idmapping of the caller. Let's
245 assume the caller has the somewhat unconventional idmapping
348 When creating a filesystem object the caller will look at the caller's
352 the caller but can differ. We will just assume they are always identical to not
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
362 2. Verify that the caller's kernel ids can be mapped up to userspace ids in the
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
380 - caller's idmapping (usually taken from ``current_user_ns()``)
384 Let's see some examples with caller/filesystem idmapping but without mount
394 caller id: u1000
395 caller idmapping: u0:k0:r4294967295
398 Both the caller and the filesystem use the identity idmapping:
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
421 caller id: u1000
422 caller idmapping: u0:k10000:r10000
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
435 It's immediately clear that while the caller's userspace id could be
436 successfully mapped down into kernel ids in the caller's idmapping the kernel
449 caller id: u1000
450 caller idmapping: u0:k10000:r10000
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
468 First, that we can't allow a caller to ultimately write to disk with another
470 with the caller's or another idmapping. But that solution is limited to a few
474 Second, the caller will usually not be able to create any files or access
476 kernel ids map up into valid userspace ids in the caller's idmapping
482 2. Map kernel ids up to userspace ids in the caller's idmapping::
492 caller idmapping: u0:k10000:r10000
503 2. Map the kernel id up into a userspace id in the caller's idmapping::
508 filesystem idmapping cannot be mapped up to a userspace id in the caller's
518 caller idmapping: u0:k10000:r10000
529 2. Map the kernel id up into a userspace id in the caller's idmapping::
534 the filesystem idmapping cannot be mapped to a userspace id in the caller's
538 Note how in the last two examples things would be simple if the caller would be
548 2. Map the kernel id up into a userspace id in the caller's idmapping::
555 The examples we've seen in the previous section where the caller's idmapping
621 is then used to translate from the caller's idmapping to the filesystem's
649 If a uid or gid has been generated using the filesystem or caller's idmapping
692 a filesystem or caller idmapping will cause a compilation error.
717 The ``mapped_fs*id()`` functions translate the caller's kernel ids into
719 remapping the caller's VFS ids using the mount's idmapping::
721 /* Map the caller's VFS id up into a userspace id in the mount's idmapping. */
734 caller idmapping: u0:k10000:r10000
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
757 Finally, when the kernel reports the owner to the caller it will turn the
758 VFS id in the mount's idmapping into a userspace id in the caller's
767 The kernel maps this to ``k11000`` in the caller's idmapping. Usually the
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. */
802 caller id: u1000
803 caller idmapping: u0:k10000:r10000
807 When the caller is using a non-initial idmapping the common case is to attach
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
824 2. Verify that the caller's kernel ids can be mapped to userspace ids in the
836 caller id: u1000
837 caller idmapping: u0:k10000:r10000
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
857 2. Verify that the caller's kernel ids can be mapped to userspace ids in the
870 caller idmapping: u0:k10000:r10000
891 3. Map the VFS id up into a userspace id in the caller's idmapping::
896 Earlier, the caller's kernel id couldn't be crossmapped in the filesystems's
907 caller idmapping: u0:k10000:r10000
928 3. Map the VFS id up into a userspace id in the caller's idmapping::
942 idmappings when either the caller, the filesystem or both uses a non-initial
943 idmapping. A wide range of usecases exist when the caller is using
948 be crossmapped between the caller's and the filesystem's idmapping.
951 caller's or filesystem's idmapping according to the mount's idmapping.
954 they also work when both the caller and the filesystem use the initial
978 caller id: u1125
979 caller idmapping: u0:k0:r4294967295
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
997 2. Verify that the caller's filesystem ids can be mapped to userspace ids in the
1004 Now let's briefly look at what ownership the caller with id ``u1125`` will see
1010 caller idmapping: u0:k0:r4294967295
1028 3. Map the VFS id up into a userspace id in the caller's idmapping::
1033 So ultimately the caller will be reported that the file belongs to ``u1125``
1034 which is the caller's userspace id on their workstation in our example.