<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel/linux.git/fs/namespace.c, branch linux-6.0.y</title>
<subtitle>Linux kernel stable tree (mirror)</subtitle>
<id>https://git.radix-linux.su/kernel/linux.git/atom?h=linux-6.0.y</id>
<link rel='self' href='https://git.radix-linux.su/kernel/linux.git/atom?h=linux-6.0.y'/>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/'/>
<updated>2022-08-17T09:27:11+00:00</updated>
<entry>
<title>fs: require CAP_SYS_ADMIN in target namespace for idmapped mounts</title>
<updated>2022-08-17T09:27:11+00:00</updated>
<author>
<name>Seth Forshee</name>
<email>sforshee@digitalocean.com</email>
</author>
<published>2022-08-16T16:47:52+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=bf1ac16edf6770a92bc75cf2373f1f9feea398a4'/>
<id>urn:sha1:bf1ac16edf6770a92bc75cf2373f1f9feea398a4</id>
<content type='text'>
Idmapped mounts should not allow a user to map file ownsership into a
range of ids which is not under the control of that user. However, we
currently don't check whether the mounter is privileged wrt to the
target user namespace.

Currently no FS_USERNS_MOUNT filesystems support idmapped mounts, thus
this is not a problem as only CAP_SYS_ADMIN in init_user_ns is allowed
to set up idmapped mounts. But this could change in the future, so add a
check to refuse to create idmapped mounts when the mounter does not have
CAP_SYS_ADMIN in the target user namespace.

Fixes: bd303368b776 ("fs: support mapped mounts of mapped filesystems")
Signed-off-by: Seth Forshee &lt;sforshee@digitalocean.com&gt;
Reviewed-by: Christian Brauner (Microsoft) &lt;brauner@kernel.org&gt;
Link: https://lore.kernel.org/r/20220816164752.2595240-1-sforshee@digitalocean.com
Signed-off-by: Christian Brauner (Microsoft) &lt;brauner@kernel.org&gt;
</content>
</entry>
<entry>
<title>switch try_to_unlazy_next() to __legitimize_mnt()</title>
<updated>2022-07-05T20:18:21+00:00</updated>
<author>
<name>Al Viro</name>
<email>viro@zeniv.linux.org.uk</email>
</author>
<published>2022-07-05T16:22:46+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=7e4745a09426b3fe63e9fbea3190e0f8500820a4'/>
<id>urn:sha1:7e4745a09426b3fe63e9fbea3190e0f8500820a4</id>
<content type='text'>
The tricky case (__legitimize_mnt() failing after having grabbed
a reference) can be trivially dealt with by leaving nd-&gt;path.mnt
non-NULL, for terminate_walk() to drop it.

legitimize_mnt() becomes static after that.

Signed-off-by: Al Viro &lt;viro@zeniv.linux.org.uk&gt;
</content>
</entry>
<entry>
<title>Merge tag 'pull-18-rc1-work.mount' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs</title>
<updated>2022-06-05T02:00:05+00:00</updated>
<author>
<name>Linus Torvalds</name>
<email>torvalds@linux-foundation.org</email>
</author>
<published>2022-06-05T02:00:05+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=cbd76edeabd5ed078391abb2323b7aee790cdc04'/>
<id>urn:sha1:cbd76edeabd5ed078391abb2323b7aee790cdc04</id>
<content type='text'>
Pull mount handling updates from Al Viro:
 "Cleanups (and one fix) around struct mount handling.

  The fix is usermode_driver.c one - once you've done kern_mount(), you
  must kern_unmount(); simple mntput() will end up with a leak. Several
  failure exits in there messed up that way... In practice you won't hit
  those particular failure exits without fault injection, though"

* tag 'pull-18-rc1-work.mount' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs:
  move mount-related externs from fs.h to mount.h
  blob_to_mnt(): kern_unmount() is needed to undo kern_mount()
  m-&gt;mnt_root-&gt;d_inode-&gt;i_sb is a weird way to spell m-&gt;mnt_sb...
  linux/mount.h: trim includes
  uninline may_mount() and don't opencode it in fspick(2)/fsopen(2)
</content>
</entry>
<entry>
<title>uninline may_mount() and don't opencode it in fspick(2)/fsopen(2)</title>
<updated>2022-05-20T03:25:10+00:00</updated>
<author>
<name>Al Viro</name>
<email>viro@zeniv.linux.org.uk</email>
</author>
<published>2022-03-01T05:05:29+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=a5f85d7834f7e1456e799c79a2a83fc11b90cfe2'/>
<id>urn:sha1:a5f85d7834f7e1456e799c79a2a83fc11b90cfe2</id>
<content type='text'>
It's done once per (mount-related) syscall and there's no point
whatsoever making it inline.

Signed-off-by: Al Viro &lt;viro@zeniv.linux.org.uk&gt;
</content>
</entry>
<entry>
<title>fs: hold writers when changing mount's idmapping</title>
<updated>2022-05-12T08:12:00+00:00</updated>
<author>
<name>Christian Brauner</name>
<email>christian.brauner@ubuntu.com</email>
</author>
<published>2022-05-10T09:58:40+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=e1bbcd277a53e08d619ffeec56c5c9287f2bf42f'/>
<id>urn:sha1:e1bbcd277a53e08d619ffeec56c5c9287f2bf42f</id>
<content type='text'>
Hold writers when changing a mount's idmapping to make it more robust.

The vfs layer takes care to retrieve the idmapping of a mount once
ensuring that the idmapping used for vfs permission checking is
identical to the idmapping passed down to the filesystem.

For ioctl codepaths the filesystem itself is responsible for taking the
idmapping into account if they need to. While all filesystems with
FS_ALLOW_IDMAP raised take the same precautions as the vfs we should
enforce it explicitly by making sure there are no active writers on the
relevant mount while changing the idmapping.

This is similar to turning a mount ro with the difference that in
contrast to turning a mount ro changing the idmapping can only ever be
done once while a mount can transition between ro and rw as much as it
wants.

This is a minor user-visible change. But it is extremely unlikely to
matter. The caller must've created a detached mount via OPEN_TREE_CLONE
and then handed that O_PATH fd to another process or thread which then
must've gotten a writable fd for that mount and started creating files
in there while the caller is still changing mount properties. While not
impossible it will be an extremely rare corner-case and should in
general be considered a bug in the application. Consider making a mount
MOUNT_ATTR_NOEXEC or MOUNT_ATTR_NODEV while allowing someone else to
perform lookups or exec'ing in parallel by handing them a copy of the
OPEN_TREE_CLONE fd or another fd beneath that mount.

Link: https://lore.kernel.org/r/20220510095840.152264-1-brauner@kernel.org
Cc: Seth Forshee &lt;seth.forshee@digitalocean.com&gt;
Cc: Christoph Hellwig &lt;hch@lst.de&gt;
Cc: Al Viro &lt;viro@zeniv.linux.org.uk&gt;
Cc: linux-fsdevel@vger.kernel.org
Signed-off-by: Christian Brauner (Microsoft) &lt;brauner@kernel.org&gt;
</content>
</entry>
<entry>
<title>fs: unset MNT_WRITE_HOLD on failure</title>
<updated>2022-04-21T15:57:37+00:00</updated>
<author>
<name>Christian Brauner</name>
<email>brauner@kernel.org</email>
</author>
<published>2022-04-20T13:19:25+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=0014edaedfd804dbf35b009808789325ca615716'/>
<id>urn:sha1:0014edaedfd804dbf35b009808789325ca615716</id>
<content type='text'>
After mnt_hold_writers() has been called we will always have set MNT_WRITE_HOLD
and consequently we always need to pair mnt_hold_writers() with
mnt_unhold_writers(). After the recent cleanup in [1] where Al switched from a
do-while to a for loop the cleanup currently fails to unset MNT_WRITE_HOLD for
the first mount that was changed. Fix this and make sure that the first mount
will be cleaned up and add some comments to make it more obvious.

Link: https://lore.kernel.org/lkml/0000000000007cc21d05dd0432b8@google.com
Link: https://lore.kernel.org/lkml/00000000000080e10e05dd043247@google.com
Link: https://lore.kernel.org/r/20220420131925.2464685-1-brauner@kernel.org
Fixes: e257039f0fc7 ("mount_setattr(): clean the control flow and calling conventions") [1]
Cc: Hillf Danton &lt;hdanton@sina.com&gt;
Cc: Christoph Hellwig &lt;hch@lst.de&gt;
Cc: Al Viro &lt;viro@zeniv.linux.org.uk&gt;
Reported-by: syzbot+10a16d1c43580983f6a2@syzkaller.appspotmail.com
Reported-by: syzbot+306090cfa3294f0bbfb3@syzkaller.appspotmail.com
Reviewed-by: Christoph Hellwig &lt;hch@lst.de&gt;
Signed-off-by: Christian Brauner (Microsoft) &lt;brauner@kernel.org&gt;
</content>
</entry>
<entry>
<title>Merge branch 'work.misc' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs</title>
<updated>2022-04-02T02:57:03+00:00</updated>
<author>
<name>Linus Torvalds</name>
<email>torvalds@linux-foundation.org</email>
</author>
<published>2022-04-02T02:57:03+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=88e6c0207623874922712e162e25d9dafd39661e'/>
<id>urn:sha1:88e6c0207623874922712e162e25d9dafd39661e</id>
<content type='text'>
Pull vfs updates from Al Viro:
 "Assorted bits and pieces"

* 'work.misc' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs:
  aio: drop needless assignment in aio_read()
  clean overflow checks in count_mounts() a bit
  seq_file: fix NULL pointer arithmetic warning
  uml/x86: use x86 load_unaligned_zeropad()
  asm/user.h: killed unused macros
  constify struct path argument of finish_automount()/do_add_mount()
  fs: Remove FIXME comment in generic_write_checks()
</content>
</entry>
<entry>
<title>Merge tag 'fs.rt.v5.18' of git://git.kernel.org/pub/scm/linux/kernel/git/brauner/linux</title>
<updated>2022-03-24T17:06:43+00:00</updated>
<author>
<name>Linus Torvalds</name>
<email>torvalds@linux-foundation.org</email>
</author>
<published>2022-03-24T17:06:43+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=2e2d4650b34ffe0a39f70acc9429a58d94e39236'/>
<id>urn:sha1:2e2d4650b34ffe0a39f70acc9429a58d94e39236</id>
<content type='text'>
Pull mount attributes PREEMPT_RT update from Christian Brauner:
 "This contains Sebastian's fix to make changing mount
  attributes/getting write access compatible with CONFIG_PREEMPT_RT.

  The change only applies when users explicitly opt-in to real-time via
  CONFIG_PREEMPT_RT otherwise things are exactly as before. We've waited
  quite a long time with this to make sure folks could take a good look"

* tag 'fs.rt.v5.18' of git://git.kernel.org/pub/scm/linux/kernel/git/brauner/linux:
  fs/namespace: Boost the mount_lock.lock owner instead of spinning on PREEMPT_RT.
</content>
</entry>
<entry>
<title>Merge tag 'fs.v5.18' of git://git.kernel.org/pub/scm/linux/kernel/git/brauner/linux</title>
<updated>2022-03-24T16:55:15+00:00</updated>
<author>
<name>Linus Torvalds</name>
<email>torvalds@linux-foundation.org</email>
</author>
<published>2022-03-24T16:55:15+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=15f2e3d6c1f713050d2d51f822fc4253f67ae7ac'/>
<id>urn:sha1:15f2e3d6c1f713050d2d51f822fc4253f67ae7ac</id>
<content type='text'>
Pull mount_setattr updates from Christian Brauner:
 "This contains a few more patches to massage the mount_setattr()
  codepaths and one minor fix to reuse a helper we added some time back.

  The final two patches do similar cleanups in different ways. One patch
  is mine and the other is Al's who was nice enough to give me a branch
  for it.

  Since his came in later and my branch had been sitting in -next for
  quite some time we just put his on top instead of swap them"

* tag 'fs.v5.18' of git://git.kernel.org/pub/scm/linux/kernel/git/brauner/linux:
  mount_setattr(): clean the control flow and calling conventions
  fs: clean up mount_setattr control flow
  fs: don't open-code mnt_hold_writers()
  fs: simplify check in mount_setattr_commit()
  fs: add mnt_allow_writers() and simplify mount_setattr_prepare()
</content>
</entry>
<entry>
<title>mount: warn only once about timestamp range expiration</title>
<updated>2022-03-22T22:57:01+00:00</updated>
<author>
<name>Anthony Iliopoulos</name>
<email>ailiop@suse.com</email>
</author>
<published>2022-03-22T21:39:22+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=a128b054ce029554a4a52fc3abb8c1df8bafcaef'/>
<id>urn:sha1:a128b054ce029554a4a52fc3abb8c1df8bafcaef</id>
<content type='text'>
Commit f8b92ba67c5d ("mount: Add mount warning for impending timestamp
expiry") introduced a mount warning regarding filesystem timestamp
limits, that is printed upon each writable mount or remount.

This can result in a lot of unnecessary messages in the kernel log in
setups where filesystems are being frequently remounted (or mounted
multiple times).

Avoid this by setting a superblock flag which indicates that the warning
has been emitted at least once for any particular mount, as suggested in
[1].

Link: https://lore.kernel.org/CAHk-=wim6VGnxQmjfK_tDg6fbHYKL4EFkmnTjVr9QnRqjDBAeA@mail.gmail.com/ [1]
Link: https://lkml.kernel.org/r/20220119202934.26495-1-ailiop@suse.com
Signed-off-by: Anthony Iliopoulos &lt;ailiop@suse.com&gt;
Reviewed-by: Christoph Hellwig &lt;hch@lst.de&gt;
Acked-by: Christian Brauner &lt;christian.brauner@ubuntu.com&gt;
Reviewed-by: Darrick J. Wong &lt;djwong@kernel.org&gt;
Cc: Alexander Viro &lt;viro@zeniv.linux.org.uk&gt;
Cc: Deepa Dinamani &lt;deepa.kernel@gmail.com&gt;
Signed-off-by: Andrew Morton &lt;akpm@linux-foundation.org&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
</content>
</entry>
</feed>
