Lines Matching full:ownership

7 reading from or writing ownership to disk, reporting ownership to userspace, or
172 When a process creates or wants to change ownership of a file, or when the
173 ownership of a file is read from disk by a filesystem, the userspace id is
200 example, it is used when reporting back the ownership of a file to userspace
240 ownership information about the file the kernel can't simply map the id back up
350 but they are exclusively used when determining file ownership which is why they
495 In order to report ownership to userspace the kernel uses the crossmapping
509 idmapping. Thus, the kernel will report the ownership of this file as the
521 In order to report ownership to userspace the kernel uses the crossmapping
535 idmapping. Thus, the kernel will report the ownership of this file as the
575 Of course the administrator has the option to recursively change ownership via
576 ``chown()``. For example, they could change ownership so that ``dir`` and all
578 idmapping. Let's assume they change ownership so it is compatible with the
598 In both cases changing ownership recursively has grave implications. The most
599 obvious one is that ownership is changed globally and permanently. In the home
600 directory case this change in ownership would even need to happen every time the
605 inside user namespaces. But this would also change ownership globally and the
606 change in ownership is tied to the lifetime of the filesystem mount, i.e. the
607 superblock. The only way to change ownership is to completely unmount the
618 They allow to expose the same set of dentries with different ownership at
624 Idmapped mounts make it possible to change ownership in a temporary and
625 localized way. The ownership changes are restricted to a specific mount and the
626 ownership changes are tied to the lifetime of the mount. All other users and
642 filesystem ownership and mount ownership of a VFS object such as an inode. The
646 So, to distinguish idmapped mount ownership from filesystem ownership separate
665 Whenever we report ownership based on a ``vfsuid_t`` or ``vfsgid_t`` type,
666 e.g., during ``stat()``, or store ownership information in a shared VFS object
671 change ownership of an inode from an idmapped mount. After we generated
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"
680 ``kuid_t`` and ``kgid_t`` must be used. Ownership expressed via ``vfsuid_t``
742 When the caller queries the ownership of this file via ``stat()`` the kernel
829 So the ownership that lands on disk will be ``u1000``.
862 So the ownership that lands on disk will be ``u1000``.
874 In order to report ownership to userspace the kernel now does three steps using
911 Again, in order to report ownership to userspace the kernel now does three
938 Changing ownership on a home directory
955 idmapping which means users on the host can change the ownership of directories
969 depending on what ownership they would prefer to end up on the portable storage
1004 Now let's briefly look at what ownership the caller with id ``u1125`` will see