Re: [PATCH] fs: show locked and lock_ro options in mountinfo

From: Richard Weinberger <richard@nod.at>
To: Andrey Wagin <avagin@gmail.com>
Cc: linux-fsdevel <linux-fsdevel@vger.kernel.org>,
	LKML <linux-kernel@vger.kernel.org>,
	Cyrill Gorcunov <gorcunov@openvz.org>,
	Pavel Emelyanov <xemul@parallels.com>,
	"Eric W. Biederman" <ebiederm@xmission.com>,
	Alexander Viro <viro@zeniv.linux.org.uk>
Subject: Re: [PATCH] fs: show locked and lock_ro options in mountinfo
Date: Fri, 27 Mar 2015 23:47:05 +0100	[thread overview]
Message-ID: <5515DDE9.4040203@nod.at> (raw)
In-Reply-To: <CANaxB-xbG80-YbRqypYVXbnOMxBPfYep4y0suNOH7tGYs2ao2A@mail.gmail.com>

Hi!

Am 27.03.2015 um 23:35 schrieb Andrey Wagin:
> 2015-03-28 0:42 GMT+03:00 Richard Weinberger <richard.weinberger@gmail.com>:
>> On Fri, Mar 27, 2015 at 9:39 PM, Andrey Vagin <avagin@openvz.org> wrote:
>>> I don't see any reasons to hide them. This information can help to
>>> understand errors.
>>
>> Because these flags are set/read only internally by the VFS. In contrast
>> to the other flags shown by mountinfo MNT_LOCKED is not a mount option.
> 
> But this flag is set as a result of the specified user action, when he
> unshares userns and mntns. This flag affects visiable behaviour.

It is a implicit result. Used by the VFS internally.
If you expose it it becomes ABI and changing the behavior will be
tricky or impossible.

>>
>> Why does it help to debug errors?
>> How would a user know that mount() with MS_BIND returns EINVAL because
>> the mount source is MNT_LOCKED? This information is useless for her.
> 
> If I see lock_ro, I can be sure that mount -o remount,bind,rw /XXX will fail.
> If I see locked, I  know that this mount can't be umounted or moved
> and can be bind-mounted only recursively.
> 
> If a user see these flags, he can check that a mount namespace is
> configured correctly without security issues.
> 
> Sorry but I don't understand why you think that this information is
> useless for users.

You can only know if you know how the VFS works internally.
If know that EINVAL from mount(2) with MS_BIND can be caused by MNT_LOCKED
because I know the source. I bet you know the source too. But not Joey random
admin who looks into mountinfo to figure out why something does not work.

If you expose MNT_LOCKED to userspace you'll have to update also the mount(2)
manpage with all glory details of that flag.

>> If you argue like that you'd have to expose the whole VFS state to userland.
> 
> I have not noticed other MNT_LOCK_* flags. I should think more about
> what information are a really required for dumping mount namespaces.
> 
>>
>>> And this information is required for correct checkpoint/restore of mount
>>> namespaces.
>>
>> Why especially MNT_LOCKED and not all the other flags used by VFS?
> 
> My goal is to dump enough information about a mount namespace to be
> able to restore it back later. I don't know how to do this without
> knowledge about locked mounts. I will think.

How do you plan to restore a MNT_LOCKED mount?
IIRC we have currently no way to directly set MNT_LOCKED from userspace.

>> Say MNT_DOOMED?
> 
> Mounts with MNT_DOOMED are never shown in mountinfo, are they?

It was just an example. There are other flags too, did you double check
which ones you really need?

To make the story short, my concern is that exposing such flags to userspace
has to be well thought. :-)
As long they are just internal we can change them as we like, as soon userspace
depends somehow on it the pain begins.

Thanks,
//richard