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
157 outside of the filesystem context. This is best left to an explanation of user
173 ownership of a file is read from disk by a filesystem, the userspace id is
177 For instance, consider a file that is stored on disk by a filesystem as being
180 - If a filesystem were to be mounted in the initial user namespaces (as most
186 - If a filesystem were to be mounted with an idmapping of ``u0:k10000:r10000``
233 into a kernel id according to the idmapping associated with the filesystem.
234 Let's assume the filesystem was mounted with an idmapping of
241 according to the filesystem's idmapping as this would give the wrong owner if
328 Idmappings when creating filesystem objects
332 kernel functions filesystem developers are rather familiar with and which we've
342 filesystem objects. For simplicity we will only look at what happens when the
343 VFS has already completed path lookup right before it calls into the filesystem
345 called. We will also assume that the directory we're creating filesystem
348 When creating a filesystem object the caller will look at the caller's
349 filesystem ids. These are just regular ``uid_t`` and ``gid_t`` userspace ids
351 are called "filesystem ids". They are usually identical to the uid and gid of
363 filesystem's idmapping.
365 The second step is important as regular filesystem will ultimately need to map
369 even remotely risk filesystem corruption.
375 filesystem's idmapping.
381 - filesystem's idmapping (``sb->s_user_ns``)
384 Let's see some examples with caller/filesystem idmapping but without mount
396 filesystem idmapping: u0:k0:r4294967295
398 Both the caller and the filesystem use the identity idmapping:
405 filesystem's idmapping.
423 filesystem idmapping: u0:k20000:r10000
431 filesystem's idmapping::
437 ids could not be mapped up according to the filesystem's idmapping. So the
440 Note that while this example is less common, because most filesystem can't be
451 filesystem idmapping: u0:k0:r4294967295
459 filesystem's idmapping::
464 filesystem will ultimately put to disk will always be identical to the value of
469 userspace id. We could only do this if we were to mount the whole filesystem
475 directories that have stricter permissions because none of the filesystem's
478 1. Map raw userspace ids down to kernel ids in the filesystem's idmapping::
493 filesystem idmapping: u0:k0:r4294967295
498 1. Map the userspace id on disk down into a kernel id in the filesystem's
508 filesystem idmapping cannot be mapped up to a userspace id in the caller's
519 filesystem idmapping: u0:k20000:r10000
524 1. Map the userspace id on disk down into a kernel id in the filesystem's
534 the filesystem idmapping cannot be mapped to a userspace id in the caller's
539 using the initial idmapping. For a filesystem mounted with the initial
540 idmapping it would be trivial. So we only consider a filesystem with an
543 1. Map the userspace id on disk down into a kernel id in the filesystem's
556 and the filesystem's idmapping are incompatible causes various issues for
564 filesystem idmapping: u0:k30000:r10000
577 files below it can be crossmapped from the filesystem's into the container's
604 If the user is lucky, they are dealing with a filesystem that is mountable
606 change in ownership is tied to the lifetime of the filesystem mount, i.e. the
608 filesystem and mount it again in another user namespace. This is usually
610 filesystem can't anymore. And it means that ``dir`` still can't be shared
614 desirable as it doesn't require the filesystem to deal with malicious
615 filesystem images.
621 is then used to translate from the caller's idmapping to the filesystem's
627 locations where the filesystem is exposed are unaffected.
630 being mountable inside user namespaces. A filesystem could be exposed
638 Filesystem types vs idmapped mount types
642 filesystem ownership and mount ownership of a VFS object such as an inode. The
643 owner of a inode might be different when looked at from a filesystem
646 So, to distinguish idmapped mount ownership from filesystem ownership separate
649 If a uid or gid has been generated using the filesystem or caller's idmapping
656 to catch errors that originate from conflating filesystem and VFS uids and gids.
673 this ``vfsuid_t`` or ``vfsgid_t`` to become the new filesystem wide ownership.
679 ``struct posix_acl``, stores ownership information a filesystem or "global"
685 on filesystem idmappings. To prevent abusing filesystem idmappings to generate
687 or ``kgid_t`` types filesystem idmappings and mount idmappings are different
692 a filesystem or caller idmapping will cause a compilation error.
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. */
710 from_kuid(filesystem, kid) = uid
712 /* Map the filesystem's userspace id down ito a VFS id in the mount's idmapping. */
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. */
725 make_kuid(filesystem, uid) = kuid
735 filesystem idmapping: u0:k20000:r10000
738 Assume a file owned by ``u1000`` is read from disk. The filesystem maps this id
743 would usually simply use the crossmapping algorithm and map the filesystem's
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. */
754 /* Map the filesystem's userspace id down into a VFS id in the mount's idmapping. */
769 mapped to a userspace id in the filesystem's idmapping. Since ``k11000`` can't
770 be mapped up in the filesystem's idmapping directly this creation request
781 /* Map the mount's userspace id down into a kernel id in the filesystem's idmapping. */
785 userspace id in the filesystem's idmapping::
804 filesystem idmapping: u0:k20000:r10000
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. */
825 filesystem's idmapping::
838 filesystem idmapping: u0:k0:r4294967295
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. */
858 filesystem's idmapping::
871 filesystem idmapping: u0:k0:r4294967295
877 1. Map the userspace id on disk down into a kernel id in the filesystem's
885 /* Map the kernel id up into a userspace id in the filesystem's idmapping. */
898 filesystem's idmapping via the mount's idmapping. The file will now be created
908 filesystem idmapping: u0:k20000:r10000
914 1. Map the userspace id on disk down into a kernel id in the filesystem's
922 /* Map the kernel id up into a userspace id in the filesystem's idmapping. */
935 filesystem's idmapping via the mount's idmapping. The file is now owned by
942 idmappings when either the caller, the filesystem or both uses a non-initial
945 workloads. The consequence is as we have seen that for both, filesystem's
947 idmappings, access to the filesystem isn't working because the kernel ids can't
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
980 filesystem idmapping: u0:k0:r4294967295
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. */
997 2. Verify that the caller's filesystem ids can be mapped to userspace ids in the
998 filesystem's idmapping::
1011 filesystem idmapping: u0:k0:r4294967295
1014 1. Map the userspace id on disk down into a kernel id in the filesystem's
1022 /* Map the kernel id up into a userspace id in the filesystem's idmapping. */
1038 ``u1000`` using the initial idmapping and mount the filesystem with the initial