| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-Id: <20220110125600.440171-1-brauner@kernel.org>
Date: Mon, 10 Jan 2022 13:56:00 +0100
From: Christian Brauner <brauner@...nel.org>
To: Linus Torvalds <torvalds@...ux-foundation.org>
Cc: linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: [GIT PULL] fs idmapping updates
Hi Linus,
/* Summary */
This contains the work to enable the idmapping infrastructure to support
idmapped mounts of filesystems mounted with an idmapping. In addition this
contains various cleanups that avoid repeated open-coding of the same
functionality and simplify the code in quite a few places. We also finish
the renaming of the mapping helpers we started a few kernel releases back
and move them to a dedicated header to not continue polluting the fs
header needlessly with low-level idmapping helpers. With this series the fs
header only contains idmapping helpers that interact with fs objects.
Currently we only support idmapped mounts for filesystems mounted without
an idmapping themselves. This was a conscious decision mentioned in
multiple places (cf. [1]).
As explained at length in [3] it is perfectly fine to extend support for
idmapped mounts to filesystem's mounted with an idmapping should the need
arise. The need has been there for some time now (cf. [2]).
Before we can port any filesystem that is mountable with an idmapping to
support idmapped mounts in the coming cycles, we need to first extend the
mapping helpers to account for the filesystem's idmapping. This again, is
explained at length in our documentation at [3] and also in the individual
commit messages so here's an overview.
Currently, the low-level mapping helpers implement the remapping algorithms
described in [3] in a simplified manner as we could rely on the fact
that all filesystems supporting idmapped mounts are mounted without an
idmapping.
In contrast, filesystems mounted with an idmapping are very likely to not
use an identity mapping and will instead use a non-identity mapping. So the
translation step from or into the filesystem's idmapping in the remapping
algorithm cannot be skipped for such filesystems.
Non-idmapped filesystems and filesystems not supporting idmapped mounts are
unaffected by this change as the remapping algorithms can take the same
shortcut as before. If the low-level helpers detect that they are dealing
with an idmapped mount but the underlying filesystem is mounted without an
idmapping we can rely on the previous shortcut and can continue to skip the
translation step from or into the filesystem's idmapping. And of course, if
the low-level helpers detect that they are not dealing with an idmapped
mount they can simply return the relevant id unchanged; no remapping needs
to be performed at all.
These checks guarantee that only the minimal amount of work is performed.
As before, if idmapped mounts aren't used the low-level helpers are
idempotent and no work is performed at all.
Link: [1] commit 2ca4dcc4909d ("fs/mount_setattr: tighten permission checks")
Link: [2] https://github.com/containers/podman/issues/10374
Link: [3] Documentations/filesystems/idmappings.rst
Link: [4] commit a65e58e791a1 ("fs: document and rename fsid helpers")
/* Testing */
All patches are based on v5.16-rc3 and have been sitting in linux-next. No
build failures or warnings were observed and fstests are passing:
SECTION -- xfs
RECREATING -- xfs on /dev/loop4
FSTYP -- xfs (debug)
PLATFORM -- Linux/x86_64 f2-vm 5.16.0-fs.idmapped.v5.17-88a4b8c3b3c3 #42 SMP PREEMPT Mon Jan 10 10:57:44 UTC 2022
MKFS_OPTIONS -- -f -f /dev/loop5
MOUNT_OPTIONS -- /dev/loop5 /mnt/scratch
generic/633 25s ... 26s
generic/644 4s ... 16s
generic/645 209s ... 77s
generic/656 14s ... 17s
xfs/152 75s ... 70s
xfs/153 48s ... 43s
Ran: generic/633 generic/644 generic/645 generic/656 xfs/152 xfs/153
Passed all 6 tests
SECTION -- ext4
RECREATING -- ext4 on /dev/loop4
FSTYP -- ext4
PLATFORM -- Linux/x86_64 f2-vm 5.16.0-fs.idmapped.v5.17-88a4b8c3b3c3 #42 SMP PREEMPT Mon Jan 10 10:57:44 UTC 2022
MKFS_OPTIONS -- -F -F /dev/loop5
MOUNT_OPTIONS -- -o acl,user_xattr /dev/loop5 /mnt/scratch
generic/633 26s ... 17s
generic/644 16s ... 4s
generic/645 77s ... 58s
generic/656 17s ... 8s
Ran: generic/633 generic/644 generic/645 generic/656
Passed all 4 tests
SECTION -- btrfs
RECREATING -- btrfs on /dev/loop4
FSTYP -- btrfs
PLATFORM -- Linux/x86_64 f2-vm 5.16.0-fs.idmapped.v5.17-88a4b8c3b3c3 #42 SMP PREEMPT Mon Jan 10 10:57:44 UTC 2022
MKFS_OPTIONS -- -f /dev/loop5
MOUNT_OPTIONS -- /dev/loop5 /mnt/scratch
btrfs/245 11s ... 11s
generic/633 17s ... 21s
generic/644 4s ... 6s
generic/645 58s ... 60s
generic/656 8s ... 8s
Ran: btrfs/245 generic/633 generic/644 generic/645 generic/656
Passed all 5 tests
SECTION -- xfs
=========================
Ran: generic/633 generic/644 generic/645 generic/656 xfs/152 xfs/153
Passed all 6 tests
SECTION -- ext4
=========================
Ran: generic/633 generic/644 generic/645 generic/656
Passed all 4 tests
SECTION -- btrfs
=========================
Ran: btrfs/245 generic/633 generic/644 generic/645 generic/656
Passed all 5 tests
/* Conflicts */
At the time of creating this PR no merge conflicts showed up doing a test-merge
with current mainline.
There's a merge conflict reported from -next with David's fscache rewrite.
Although I'm not sure David still intends to send it for the v5.17 merge window
we covered the conflict in thread [1] where stated in [2] that the conflict is
trivial enough for you to resolve during the merge. (I'm posting the links so
you can double-check.)
[1]: https://lore.kernel.org/linux-fsdevel/20211207142405.179428-1-brauner@kernel.org
[2]: https://lore.kernel.org/linux-fsdevel/CAHk-=wjjxBRNkav+RjpdHjDZHRPAJgjdM4wTFi_oEnk0_dc67g@mail.gmail.com
At the time of creating this PR no merge conflicts were reported from
linux-next and no merge conflicts showed up doing a test-merge with current
mainline.
The following changes since commit d58071a8a76d779eedab38033ae4c821c30295a5:
Linux 5.16-rc3 (2021-11-28 14:09:19 -0800)
are available in the Git repository at:
git@...olite.kernel.org:pub/scm/linux/kernel/git/brauner/linux tags/fs.idmapped.v5.17
for you to fetch changes up to bd303368b776eead1c29e6cdda82bde7128b82a7:
fs: support mapped mounts of mapped filesystems (2021-12-05 10:28:57 +0100)
Please consider pulling these changes from the signed fs.idmapped.v5.17 tag.
Thanks!
Christian
----------------------------------------------------------------
fs.idmapped.v5.17
----------------------------------------------------------------
Christian Brauner (10):
fs: add is_idmapped_mnt() helper
fs: move mapping helpers
fs: tweak fsuidgid_has_mapping()
fs: account for filesystem mappings
docs: update mapping documentation
fs: use low-level mapping helpers
fs: remove unused low-level mapping helpers
fs: port higher-level mapping helpers
fs: add i_user_ns() helper
fs: support mapped mounts of mapped filesystems
Documentation/filesystems/idmappings.rst | 72 ----------
fs/cachefiles/bind.c | 2 +-
fs/ecryptfs/main.c | 2 +-
fs/ksmbd/smbacl.c | 19 +--
fs/ksmbd/smbacl.h | 5 +-
fs/namespace.c | 53 +++++--
fs/nfsd/export.c | 2 +-
fs/open.c | 8 +-
fs/overlayfs/super.c | 2 +-
fs/posix_acl.c | 17 ++-
fs/proc_namespace.c | 2 +-
fs/xfs/xfs_inode.c | 8 +-
fs/xfs/xfs_linux.h | 1 +
fs/xfs/xfs_symlink.c | 4 +-
include/linux/fs.h | 141 ++++++-------------
include/linux/mnt_idmapping.h | 234 +++++++++++++++++++++++++++++++
security/commoncap.c | 15 +-
17 files changed, 356 insertions(+), 231 deletions(-)
create mode 100644 include/linux/mnt_idmapping.h
Powered by blists - more mailing lists