util-linux.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* btrfs mount failure with context option and latest mount command
@ 2023-01-16 10:15 Shinichiro Kawasaki
  2023-01-17 16:42 ` Karel Zak
  0 siblings, 1 reply; 3+ messages in thread
From: Shinichiro Kawasaki @ 2023-01-16 10:15 UTC (permalink / raw)
  To: linux-btrfs, linux-fsdevel, util-linux
  Cc: Damien Le Moal, Johannes Thumshirn, Naohiro Aota

I observe mount command with -o context option fails for btrfs, using mount
command built from the latest util-linux master branch code (git hash
dbf77f7a1).

$ sudo mount -o context="system_u:object_r:root_t:s0" /dev/nullb1 /mnt
mount: /mnt: wrong fs type, bad option, bad superblock on /dev/nullb1, missing codepage or helper program, or other error.
       dmesg(1) may have more information after failed mount system call.

Kernel reports an SELinux error message:

[565959.593054][T12131] SELinux: mount invalid.  Same superblock, different security settings for (dev nullb1, type btrfs)

Is this a known issue?

Details:

- Mount succeeds without the -o context option.
- Ext4 succeeds to mount with the option.
- Mount succeeds rolling back util-linux code to older git hash 8241fb005,
  which was committed on January 3rd. After this commit, a number of commits
  were merged to util-linux to use fsconfig syscall for mount in place of
  mount syscall.

Then the new fsconfig syscall looks the trigger of the failure. I took a look in
the code of mount path and saw that btrfs is not modified to use struct
fs_context for the fsconfig syscall. The -o context option is parsed and kept in
security field of fs_context, but it is not passed to btrfs_mount.

-- 
Shin'ichiro Kawasaki

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: btrfs mount failure with context option and latest mount command
  2023-01-16 10:15 btrfs mount failure with context option and latest mount command Shinichiro Kawasaki
@ 2023-01-17 16:42 ` Karel Zak
  2023-01-19  6:13   ` Christoph Hellwig
  0 siblings, 1 reply; 3+ messages in thread
From: Karel Zak @ 2023-01-17 16:42 UTC (permalink / raw)
  To: Shinichiro Kawasaki
  Cc: linux-btrfs, linux-fsdevel, util-linux, Damien Le Moal,
	Johannes Thumshirn, Naohiro Aota

On Mon, Jan 16, 2023 at 10:15:58AM +0000, Shinichiro Kawasaki wrote:
> I observe mount command with -o context option fails for btrfs, using mount
> command built from the latest util-linux master branch code (git hash
> dbf77f7a1).
> 
> $ sudo mount -o context="system_u:object_r:root_t:s0" /dev/nullb1 /mnt
> mount: /mnt: wrong fs type, bad option, bad superblock on /dev/nullb1, missing codepage or helper program, or other error.
>        dmesg(1) may have more information after failed mount system call.
> 
> Kernel reports an SELinux error message:
> 
> [565959.593054][T12131] SELinux: mount invalid.  Same superblock, different security settings for (dev nullb1, type btrfs)
> 
> Is this a known issue?

Not for me.

> Details:
> 
> - Mount succeeds without the -o context option.
> - Ext4 succeeds to mount with the option.
> - Mount succeeds rolling back util-linux code to older git hash 8241fb005,
>   which was committed on January 3rd. After this commit, a number of commits
>   were merged to util-linux to use fsconfig syscall for mount in place of
>   mount syscall.
> 
> Then the new fsconfig syscall looks the trigger of the failure. I took a look in
> the code of mount path and saw that btrfs is not modified to use struct
> fs_context for the fsconfig syscall. The -o context option is parsed and kept in
> security field of fs_context, but it is not passed to btrfs_mount.

It's a serious issue if btrfs is not ready for the new kernel fsconfig
interface. I guess libmount cannot do anything else in this case
(well, we can switch back to classic mount(2), but it sounds as a
wrong solution).

    Karel

-- 
 Karel Zak  <kzak@redhat.com>
 http://karelzak.blogspot.com


^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: btrfs mount failure with context option and latest mount command
  2023-01-17 16:42 ` Karel Zak
@ 2023-01-19  6:13   ` Christoph Hellwig
  0 siblings, 0 replies; 3+ messages in thread
From: Christoph Hellwig @ 2023-01-19  6:13 UTC (permalink / raw)
  To: Karel Zak
  Cc: Shinichiro Kawasaki, linux-btrfs, linux-fsdevel, util-linux,
	Damien Le Moal, Johannes Thumshirn, Naohiro Aota, David Howells,
	Al Viro

On Tue, Jan 17, 2023 at 05:42:34PM +0100, Karel Zak wrote:
> It's a serious issue if btrfs is not ready for the new kernel fsconfig
> interface. I guess libmount cannot do anything else in this case
> (well, we can switch back to classic mount(2), but it sounds as a
> wrong solution).

Unfortunately a lot of file systems haven't been converted to the
fsconfig code yet, it's another case of adding new infrastructure to
the kernel then not following up on the conversion, and all too common
patter unfortunately :(  btrfs might be the only major disk file system,
but there's lot of others.

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2023-01-19  6:14 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2023-01-16 10:15 btrfs mount failure with context option and latest mount command Shinichiro Kawasaki
2023-01-17 16:42 ` Karel Zak
2023-01-19  6:13   ` Christoph Hellwig

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).