The Linux Kernel Mailing List
 help / color / mirror / Atom feed
From: ebiederm@xmission.com (Eric W. Biederman)
To: Ram Pai <linuxram@us.ibm.com>
Cc: Dawid Ciezarkiewicz <dawid.ciezarkiewicz@rubrik.com>,
	linux-kernel@vger.kernel.org, <linux-fsdevel@vger.kernel.org>
Subject: Re: Read-only `slaves` with shared subtrees?
Date: Wed, 20 Sep 2017 18:06:55 -0500	[thread overview]
Message-ID: <87shfh0y28.fsf@xmission.com> (raw)
In-Reply-To: <87377h2d4a.fsf@xmission.com> (Eric W. Biederman's message of "Wed, 20 Sep 2017 17:56:21 -0500")

ebiederm@xmission.com (Eric W. Biederman) writes:

> Ram Pai <linuxram@us.ibm.com> writes:
>
>> sorry forgot to copy Eric.
>
> Adding fs-devel as well.
>
>> On Wed, Sep 20, 2017 at 12:39:54PM -0700, Ram Pai wrote:
>>> On Tue, Sep 19, 2017 at 04:18:02PM -0700, Dawid Ciezarkiewicz wrote:
>>> > On Mon, Sep 18, 2017 at 1:47 PM, Ram Pai <linuxram@us.ibm.com> wrote:
>>> > > It is possible to make a slave mount readonly, by  remounting it with
>>> > > 'ro' flags.
>>> > >
>>> > > something like
>>> > >
>>> > > mount -o bind,remount,ro <slave-mount-dir>
>>> > >
>>> > > Any mount-propagation events reaching a read-only-slave does
>>> > > inherit the slave attribute. However it does not inherit the
>>> > > read-only attribute.
>>> > 
>>> > I did try manually remounting, and it worked for me. If this could be
>>> > done atomically
>>> >  (which I assume can't be, in the userspace) it could even be a workaround.
>>> > 
>>> > > Should it inherit? or should it not? -- that has not been thought
>>> > > off AFAICT. it think we should let it inherit.
>>> > 
>>> > It makes sense, and it would work in my use-case. I wonder
>>> > if that would break any existing expectations though.
>>> 
>>> It could break existing expectations, for mounts created by propagation.
>>> This needs to be thought through. Also Should the same semantics
>>> apply to MNT_NOSUID, MNT_NOEXEC etc etc? 
>>> 
>>> Copying Eric. he should be able to tell if any of the container
>>> infrastructure assumes anything about mounts propagated to read-only
>>> mounts.
>
> *Blink*
>
> Let me reiterate what I think I am seeing.  The properties of a
> propogated mount taking on attributes from the propagation node, where
> the mount is propagated too.
>
> I honestly can't say if any code cares today, but this feels like it
> will break the principle of least surprise and break someone.

Thinking about this a little I am almost certain this will break
something.

A common pattern for containers is to have a read-only shared portion
typically the rootfs and then other mounts that are read-write.  If all
of your propagation nodes hang off of a big read-only mount (and
therefore need to be read-only) forcing everything else to propagate
into the container as read-only is likely going to break something.

> We can safely add this extension by adding a new flag or flags that can
> be set on a pnode that will give the desired semantics.  So I expect
> that is a better model then adding new semantics to MNT_RDONLY.

Which means I think to do this safely we really do need to add a new
flag.

Eric


>>> > I could at least test such a patch, it seems like a tiny change.
>>> > Should I give it a try and submit a patch? If you could PM me any pointers
>>> > it could help a lot since I'm not familiar with FS internals. So far I got here:
>>> 
>>> Here is a rough patch which will accomplish what you want; not
>>> compile-tested nor tested.
>>> 
>>> 
>>> diff --git a/fs/namespace.c b/fs/namespace.c
>>> index f8893dc..3239adc 100644
>>> --- a/fs/namespace.c
>>> +++ b/fs/namespace.c
>>> @@ -1061,6 +1061,9 @@ static struct mount *clone_mnt(struct mount *old, struct dentry *root,
>>>  	list_add_tail(&mnt->mnt_instance, &sb->s_mounts);
>>>  	unlock_mount_hash();
>>>  
>>> +	if (flag & CL_READONLY)
>>> +		mnt->mnt.mnt_flags |= MNT_READONLY;
>>> +
>>>  	if ((flag & CL_SLAVE) ||
>>>  	    ((flag & CL_SHARED_TO_SLAVE) && IS_MNT_SHARED(old))) {
>>>  		list_add(&mnt->mnt_slave, &old->mnt_slave_list);
>>> diff --git a/fs/pnode.c b/fs/pnode.c
>>> index 53d411a..aeb5b47 100644
>>> --- a/fs/pnode.c
>>> +++ b/fs/pnode.c
>>> @@ -262,6 +262,8 @@ static int propagate_one(struct mount *m)
>>>  	/* Notice when we are propagating across user namespaces */
>>>  	if (m->mnt_ns->user_ns != user_ns)
>>>  		type |= CL_UNPRIVILEGED;
>>> +	if (m->mnt.mnt_flags & MNT_READONLY)
>>> +		type |= CL_READONLY;
>>>  	child = copy_tree(last_source, last_source->mnt.mnt_root, type);
>>>  	if (IS_ERR(child))
>>>  		return PTR_ERR(child);
>>> diff --git a/fs/pnode.h b/fs/pnode.h
>>> index dc87e65..7c59469 100644
>>> --- a/fs/pnode.h
>>> +++ b/fs/pnode.h
>>> @@ -29,6 +29,7 @@
>>>  #define CL_SHARED_TO_SLAVE	0x20
>>>  #define CL_UNPRIVILEGED		0x40
>>>  #define CL_COPY_MNT_NS_FILE	0x80
>>> +#define CL_READONLY		0x100
>>>  
>>>  #define CL_COPY_ALL		(CL_COPY_UNBINDABLE | CL_COPY_MNT_NS_FILE)
>>>  
>>> RP

  reply	other threads:[~2017-09-20 23:07 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-09-15 17:57 Read-only `slaves` with shared subtrees? Dawid Ciezarkiewicz
2017-09-18 20:47 ` Ram Pai
2017-09-19 23:18   ` Dawid Ciezarkiewicz
2017-09-20 19:39     ` Ram Pai
2017-09-20 19:41       ` Ram Pai
2017-09-20 22:56         ` Eric W. Biederman
2017-09-20 23:06           ` Eric W. Biederman [this message]
2017-09-21  0:39             ` Ram Pai
2017-09-21  3:00               ` Dawid Ciezarkiewicz
2017-09-21 19:14                 ` Ram Pai
2017-09-22 18:43                   ` Dawid Ciezarkiewicz
2017-09-29 23:02                     ` Dawid Ciezarkiewicz
2017-10-09  0:15                       ` Ram Pai
2017-10-09 21:39                         ` Dawid Ciezarkiewicz
2017-10-19 18:13                           ` Ram Pai
2017-10-20  2:23                             ` Eric W. Biederman

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87shfh0y28.fsf@xmission.com \
    --to=ebiederm@xmission.com \
    --cc=dawid.ciezarkiewicz@rubrik.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linuxram@us.ibm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox