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.
379 filesystem idmapping: u0:k0:r4294967295
381 Both the caller and the filesystem use the identity idmapping:
388 filesystem's idmapping.
406 filesystem idmapping: u0:k20000:r10000
414 filesystem's idmapping::
420 ids could not be mapped up according to the filesystem's idmapping. So the
423 Note that while this example is less common, because most filesystem can't be
434 filesystem idmapping: u0:k0:r4294967295
442 filesystem's idmapping::
447 filesystem will ultimately put to disk will always be identical to the value of
458 directories that have stricter permissions because none of the filesystem's
461 1. Map raw userspace ids down to kernel ids in the filesystem's idmapping::
476 filesystem idmapping: u0:k0:r4294967295
481 1. Map the userspace id on disk down into a kernel id in the filesystem's
491 filesystem idmapping cannot be mapped up to a userspace id in the caller's
502 filesystem idmapping: u0:k20000:r10000
507 1. Map the userspace id on disk down into a kernel id in the filesystem's
517 the filesystem idmapping cannot be mapped to a userspace id in the caller's
522 using the initial idmapping. For a filesystem mounted with the initial
523 idmapping it would be trivial. So we only consider a filesystem with an
526 1. Map the userspace id on disk down into a kernel id in the filesystem's
539 and the filesystem's idmapping are incompatible causes various issues for
547 filesystem idmapping: u0:k30000:r10000
560 files below it can be crossmapped from the filesystem's into the container's
587 If the user is lucky, they are dealing with a filesystem that is mountable
589 change in ownership is tied to the lifetime of the filesystem mount, i.e. the
591 filesystem and mount it again in another user namespace. This is usually
593 filesystem can't anymore. And it means that ``dir`` still can't be shared
597 desirable as it doesn't require the filesystem to deal with malicious
598 filesystem images.
604 is then used to translate from the caller's idmapping to the filesystem's
610 locations where the filesystem is exposed are unaffected.
613 being mountable inside user namespaces. A filesystem could be exposed
630 The ``i_*id_into_mnt()`` functions translate filesystem's kernel ids into
633 /* Map the filesystem's kernel id up into a userspace id in the filesystem's idmapping. */
634 from_kuid(filesystem, kid) = uid
636 /* Map the filesystem's userspace id down ito a kernel id in the mount's idmapping. */
642 kernel ids in the filesystem's idmapping. This translation is achieved by
648 /* Map the mount's userspace id down into a kernel id in the filesystem's idmapping. */
649 make_kuid(filesystem, uid) = kuid
655 filesystem idmapping: u0:k20000:r10000
658 Assume a file owned by ``u1000`` is read from disk. The filesystem maps this id
663 would usually simply use the crossmapping algorithm and map the filesystem's
667 first call ``i_uid_into_mnt()`` thereby translating the filesystem's kernel id
671 /* Map the filesystem's kernel id up into a userspace id. */
674 /* Map the filesystem's userspace id down ito a kernel id in the mount's idmapping. */
688 mapped to a userspace id in the filesystem's idmapping. Since ``k11000`` can't
689 be mapped up in the filesystem's idmapping directly this creation request
700 /* Map the mount's userspace id down into a kernel id in the filesystem's idmapping. */
704 userspace id in the filesystem's idmapping::
722 filesystem idmapping: u0:k20000:r10000
732 2. Translate the caller's kernel id into a kernel id in the filesystem's
739 /* Map the userspace id down into a kernel id in the filesystem's idmapping. */
743 filesystem's idmapping::
756 filesystem idmapping: u0:k0:r4294967295
765 2. Translate the caller's kernel id into a kernel id in the filesystem's
772 /* Map the userspace id down into a kernel id in the filesystem's idmapping. */
776 filesystem's idmapping::
789 filesystem idmapping: u0:k0:r4294967295
795 1. Map the userspace id on disk down into a kernel id in the filesystem's
803 /* Map the kernel id up into a userspace id in the filesystem's idmapping. */
815 filesystem's idmapping via the mount's idmapping. The file will now be created
825 filesystem idmapping: u0:k20000:r10000
831 1. Map the userspace id on disk down into a kernel id in the filesystem's
839 /* Map the kernel id up into a userspace id in the filesystem's idmapping. */
851 filesystem's idmapping via the mount's idmapping. The file is now owned by
858 idmappings when either the caller, the filesystem or both uses a non-initial
861 workloads. The consequence is as we have seen that for both, filesystem's
863 idmappings, access to the filesystem isn't working because the kernel ids can't
864 be crossmapped between the caller's and the filesystem's idmapping.
867 caller's or filesystem's idmapping according to the mount's idmapping.
870 they also work when both the caller and the filesystem use the initial
896 filesystem idmapping: u0:k0:r4294967295
903 2. Translate the caller's kernel id into a kernel id in the filesystem's
910 /* Map the userspace id down into a kernel id in the filesystem's idmapping. */
914 filesystem's idmapping::
927 filesystem idmapping: u0:k0:r4294967295
930 1. Map the userspace id on disk down into a kernel id in the filesystem's
938 /* Map the kernel id up into a userspace id in the filesystem's idmapping. */
953 ``u1000`` using the initial idmapping and mount the filesystem with the initial
959 Currently, the implementation of idmapped mounts enforces that the filesystem
964 idmapping and filesystem with non-initial idmappings.
966 Based on this current restriction to filesystem mounted with the initial
974 stashing the initial user namespace the user namespace the filesystem was
976 a different user namespace attached then the filesystem was mounted with.
983 caller's kernel id into a kernel id in the filesystem's idmapping via
990 /* Map the userspace id down into a kernel id in the filesystem's idmapping. */
991 make_kuid(filesystem-idmapping, uid) = kuid
993 We know that the filesystem is always mounted with the initial idmapping as
1000 /* Map the userspace id down into a kernel id in the filesystem's idmapping. */
1003 Similarly, for ``i_*id_into_mnt()`` which translated the filesystem's kernel
1007 /* Map the kernel id up into a userspace id in the filesystem's idmapping. */
1008 from_kuid(filesystem-idmapping, kid) = uid
1013 Again, we know that the filesystem is always mounted with the initial
1018 /* Map the kernel id up into a userspace id in the filesystem's idmapping. */