Lines Matching full:filesystem
6 Most filesystem developers will have encountered idmappings. They are used when
8 for permission checking. This document is aimed at filesystem developers that
156 outside of the filesystem context. This is best left to an explanation of user
172 ownership of a file is read from disk by a filesystem, the userspace id is
176 For instance, consider a file that is stored on disk by a filesystem as being
179 - If a filesystem were to be mounted in the initial user namespaces (as most
185 - If a filesystem were to be mounted with an idmapping of ``u0:k10000:r10000``
232 into a kernel id according to the idmapping associated with the filesystem.
233 Let's assume the filesystem was mounted with an idmapping of
240 according to the filesystem's idmapping as this would give the wrong owner if
323 Idmappings when creating filesystem objects
327 kernel functions filesystem developers are rather familiar with and which we've
337 filesystem objects. For simplicity we will only look at what happens when the
338 VFS has already completed path lookup right before it calls into the filesystem
340 called. We will also assume that the directory we're creating filesystem
343 When creating a filesystem object the caller will look at the caller's
344 filesystem ids. These are just regular ``uid_t`` and ``gid_t`` userspace ids
346 are called "filesystem ids". They are usually identical to the uid and gid of
358 filesystem's idmapping.
360 The second step is important as regular filesystem will ultimately need to map
364 even remotely risk filesystem corruption.
370 filesystem's idmapping.
372 Let's see some examples with caller/filesystem idmapping but without mount
384 filesystem idmapping: u0:k0:r4294967295
386 Both the caller and the filesystem use the identity idmapping:
393 filesystem's idmapping.
411 filesystem idmapping: u0:k20000:r10000
419 filesystem's idmapping::
425 ids could not be mapped up according to the filesystem's idmapping. So the
428 Note that while this example is less common, because most filesystem can't be
439 filesystem idmapping: u0:k0:r4294967295
447 filesystem's idmapping::
452 filesystem will ultimately put to disk will always be identical to the value of
463 directories that have stricter permissions because none of the filesystem's
466 1. Map raw userspace ids down to kernel ids in the filesystem's idmapping::
481 filesystem idmapping: u0:k0:r4294967295
486 1. Map the userspace id on disk down into a kernel id in the filesystem's
496 filesystem idmapping cannot be mapped up to a userspace id in the caller's
507 filesystem idmapping: u0:k20000:r10000
512 1. Map the userspace id on disk down into a kernel id in the filesystem's
522 the filesystem idmapping cannot be mapped to a userspace id in the caller's
527 using the initial idmapping. For a filesystem mounted with the initial
528 idmapping it would be trivial. So we only consider a filesystem with an
531 1. Map the userspace id on disk down into a kernel id in the filesystem's
544 and the filesystem's idmapping are incompatible causes various issues for
552 filesystem idmapping: u0:k30000:r10000
565 files below it can be crossmapped from the filesystem's into the container's
592 If the user is lucky, they are dealing with a filesystem that is mountable
594 change in ownership is tied to the lifetime of the filesystem mount, i.e. the
596 filesystem and mount it again in another user namespace. This is usually
598 filesystem can't anymore. And it means that ``dir`` still can't be shared
602 desirable as it doesn't require the filesystem to deal with malicious
603 filesystem images.
609 is then used to translate from the caller's idmapping to the filesystem's
615 locations where the filesystem is exposed are unaffected.
618 being mountable inside user namespaces. A filesystem could be exposed
635 The ``i_*id_into_mnt()`` functions translate filesystem's kernel ids into
638 /* Map the filesystem's kernel id up into a userspace id in the filesystem's idmapping. */
639 from_kuid(filesystem, kid) = uid
641 /* Map the filesystem's userspace id down ito a kernel id in the mount's idmapping. */
647 kernel ids in the filesystem's idmapping. This translation is achieved by
653 /* Map the mount's userspace id down into a kernel id in the filesystem's idmapping. */
654 make_kuid(filesystem, uid) = kuid
660 filesystem idmapping: u0:k20000:r10000
663 Assume a file owned by ``u1000`` is read from disk. The filesystem maps this id
668 would usually simply use the crossmapping algorithm and map the filesystem's
672 first call ``i_uid_into_mnt()`` thereby translating the filesystem's kernel id
676 /* Map the filesystem's kernel id up into a userspace id. */
679 /* Map the filesystem's userspace id down ito a kernel id in the mount's idmapping. */
693 mapped to a userspace id in the filesystem's idmapping. Since ``k11000`` can't
694 be mapped up in the filesystem's idmapping directly this creation request
705 /* Map the mount's userspace id down into a kernel id in the filesystem's idmapping. */
709 userspace id in the filesystem's idmapping::
727 filesystem idmapping: u0:k20000:r10000
737 2. Translate the caller's kernel id into a kernel id in the filesystem's
744 /* Map the userspace id down into a kernel id in the filesystem's idmapping. */
748 filesystem's idmapping::
761 filesystem idmapping: u0:k0:r4294967295
770 2. Translate the caller's kernel id into a kernel id in the filesystem's
777 /* Map the userspace id down into a kernel id in the filesystem's idmapping. */
781 filesystem's idmapping::
794 filesystem idmapping: u0:k0:r4294967295
800 1. Map the userspace id on disk down into a kernel id in the filesystem's
808 /* Map the kernel id up into a userspace id in the filesystem's idmapping. */
820 filesystem's idmapping via the mount's idmapping. The file will now be created
830 filesystem idmapping: u0:k20000:r10000
836 1. Map the userspace id on disk down into a kernel id in the filesystem's
844 /* Map the kernel id up into a userspace id in the filesystem's idmapping. */
856 filesystem's idmapping via the mount's idmapping. The file is now owned by
863 idmappings when either the caller, the filesystem or both uses a non-initial
866 workloads. The consequence is as we have seen that for both, filesystem's
868 idmappings, access to the filesystem isn't working because the kernel ids can't
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
901 filesystem idmapping: u0:k0:r4294967295
908 2. Translate the caller's kernel id into a kernel id in the filesystem's
915 /* Map the userspace id down into a kernel id in the filesystem's idmapping. */
919 filesystem's idmapping::
932 filesystem idmapping: u0:k0:r4294967295
935 1. Map the userspace id on disk down into a kernel id in the filesystem's
943 /* Map the kernel id up into a userspace id in the filesystem's idmapping. */
958 ``u1000`` using the initial idmapping and mount the filesystem with the initial