linux-kernel - Re: [RFC] fs: filesystem specific options and remount

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 6 Feb 2012 23:41:16 +0100
From:	Jan Kara <jack@...e.cz>
To:	Jerome Marchand <jmarchan@...hat.com>
Cc:	linux-fsdevel@...r.kernel.org, util-linux@...r.kernel.org,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [RFC] fs: filesystem specific options and remount

On Fri 03-02-12 16:22:23, Jerome Marchand wrote:
> 
> When remounted without option specified, some filesystems keep the
> options that are already set (e.g. procfs, fat) and some reset them to
> default (e.g. devpts).
> Regarding options that are specified at remount, behavior of
> filesystems also differ: some apply them (procfs, devpts), some
> silently disregard them (e.g. fat) and some have a more elaborate
> behavior (e.g. xfs apparently allows a subset of options to be changed
> and issues warning if someone tries to change any other option).
> 
> Is there any policy regarding what the correct behavior should be?
> This variety of behaviors tends to confuse mount utility which often
> does not show the correct option actually set after a remount and
> most certainly confuses the users as well.
> 
> Here is a example of discrepancy between mount (/etc/mtab) and
> /proc/mounts:
> 
> $ grep proc /proc/mounts
> /proc /proc proc rw,relatime 0 0
> $ mount | grep proc
> proc on /proc type proc (rw)
> 
> $ mount -o remount,hidepid=2 /proc/
> $ grep proc /proc/mounts
> /proc /proc proc rw,relatime,hidepid=2 0 0
> $ mount | grep proc
> proc on /proc type proc (rw,hidepid=2)
> 
> $ mount -o remount /proc/
> $ grep proc /proc/mounts
> /proc /proc proc rw,relatime,hidepid=2 0 0
> $ mount | grep proc
> proc on /proc type proc (rw)
> 
> And here is the discrepancy: mount does not show "hidepid=2" option
> that is actually still set and enforced. Note that mount also missed
> the relatime option to begin with.
  I don't mind the discrepancy between /etc/mtab and /proc/mounts that much
(/proc/mounts is a fine replacement of /etc/mtab for me) but I agree that
handling of mount options on remount is a mess and IMHO it's made even
worse by mount(8) adding options from /etc/mtab to mount(2) syscall when
-o remount is specified. But realistically I can hardly imagine how to fix
all this mess because I'd almost bet userspace depends on the behavior.

								Honza
-- 
Jan Kara <jack@...e.cz>
SUSE Labs, CR
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/