Re: What's the status of 87b47932 patch - mnt: Implicitly add MNT_NODEV on remount as we do on mount

Re: What's the status of 87b47932 patch - mnt: Implicitly add MNT_NODEV on remount as we do on mount

[Eric W. Biederman]

joeyli <jlee-IBi9RG/b67k@public.gmane.org> writes:

> Hi Eric, 
>
> Sorry for bother you. I saw your patch:
> 	mnt: Implicitly add MNT_NODEV on remount as we do on mount
>
> Already commited in linux-next:
> https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/commit/fs/namespace.c?id=87b47932f40a11280584bce260cbdb3b5f9e8b7d
>
> But, I didn't see this patch show in v3.18-rc kernel in Linus's git tree.
> What's the status of 87b47932 patch? Does there have regression cases it
> could not be merged to v3.18 kernel?

The patch actually breaks remounting filesystems that did not have
MNT_NODEV set when theny were mounted.

The primary issue is that the bug hit at a very inopportune time in my
life (just before kernel summit) after which I had a vacation planned
and after that I had some serious job hunting and moving to do. 

Now I am busily trying to catch up on my queue and these long delayed
bug fixes are the next issue.

If folks can review/test the current version of the patch (to follow in
a moment) I would appreciate it.  Based on previous testing unless I
have a typo what I expect to see is:
lxc  - b0rked.  The old versions of lxc must be broken to fix the
       security issue.
libvirt-lxc - fixed.
Andy's thing - fixed.

Any comments on the next user namespace breaking security fix that is
being finalized would also be appreciated.

Eric

[CFT][PATCH] mnt: Implicitly add MNT_NODEV on remount when it was implicitly added by mount

[Eric W. Biederman]

Now that remount is properly enforcing the rule that you can't remove
nodev at least sandstorm.io is breaking when performing a remount.

It turns out that there is an easy intuitive solution implicitly
add nodev on remount when nodev was implicitly added on mount.

Cc: stable-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Signed-off-by: "Eric W. Biederman" <ebiederm-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org>
---
 fs/namespace.c | 8 +++++++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/fs/namespace.c b/fs/namespace.c
index 5b66b2b3624d..3a1a87dc33df 100644
--- a/fs/namespace.c
+++ b/fs/namespace.c
@@ -2098,7 +2098,13 @@ static int do_remount(struct path *path, int flags, int mnt_flags,
 	}
 	if ((mnt->mnt.mnt_flags & MNT_LOCK_NODEV) &&
 	    !(mnt_flags & MNT_NODEV)) {
-		return -EPERM;
+		/* Was the nodev implicitly added in mount? */
+		if ((mnt->mnt_ns->user_ns != &init_user_ns) &&
+		    !(sb->s_type->fs_flags & FS_USERNS_DEV_MOUNT)) {
+			mnt_flags |= MNT_NODEV;
+		} else {
+			return -EPERM;
+		}
 	}
 	if ((mnt->mnt.mnt_flags & MNT_LOCK_NOSUID) &&
 	    !(mnt_flags & MNT_NOSUID)) {
-- 
1.9.1

Re: [CFT][PATCH] mnt: Implicitly add MNT_NODEV on remount when it was implicitly added by mount

[Andy Lutomirski]

On Nov 29, 2014 4:06 PM, "Eric W. Biederman" <ebiederm-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org> wrote:
>
>
> Now that remount is properly enforcing the rule that you can't remove
> nodev at leastsandstorm.iois breaking when performing a remount.
>
> It turns out that there is an easy intuitive solution implicitly
> add nodev on remount when nodev was implicitly added on mount.

Is this intended to be a permanent fix or are you planning on
replacing it with something closer to my version for 3.19?

http://git.kernel.org/cgit/linux/kernel/git/luto/linux.git/commit/?h=userns/fix_magic_nodev&id=bf8b198add82a249d6da4ecf280c30a0865637f6

I still think that the implicit nodev behavior is a bad idea in general.

--Andy

>
> Cc:stable-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> Signed-off-by: "Eric W. Biederman" <ebiederm-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org>
> ---
>  fs/namespace.c | 8 +++++++-
>  1 file changed, 7 insertions(+), 1 deletion(-)
>
> diff --git a/fs/namespace.c b/fs/namespace.c
> index 5b66b2b3624d..3a1a87dc33df 100644
> --- a/fs/namespace.c
> +++ b/fs/namespace.c
> @@ -2098,7 +2098,13 @@ static int do_remount(struct path *path, int flags, int mnt_flags,
>         }
>         if ((mnt->mnt.mnt_flags & MNT_LOCK_NODEV) &&
>             !(mnt_flags & MNT_NODEV)) {
> -               return -EPERM;
> +               /* Was the nodev implicitly added in mount? */
> +               if ((mnt->mnt_ns->user_ns != &init_user_ns) &&
> +                   !(sb->s_type->fs_flags & FS_USERNS_DEV_MOUNT)) {
> +                       mnt_flags |= MNT_NODEV;
> +               } else {
> +                       return -EPERM;
> +               }
>         }
>         if ((mnt->mnt.mnt_flags & MNT_LOCK_NOSUID) &&
>             !(mnt_flags & MNT_NOSUID)) {
> --
> 1.9.1
>

Re: [CFT][PATCH] mnt: Implicitly add MNT_NODEV on remount when it was implicitly added by mount

[Eric W. Biederman]

Andy Lutomirski <luto-kltTT9wpgjJwATOyAt5JVQ@public.gmane.org> writes:

> On Nov 29, 2014 4:06 PM, "Eric W. Biederman" <ebiederm-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org> wrote:
>>
>>
>> Now that remount is properly enforcing the rule that you can't remove
>> nodev at leastsandstorm.iois breaking when performing a remount.
>>
>> It turns out that there is an easy intuitive solution implicitly
>> add nodev on remount when nodev was implicitly added on mount.
>
> Is this intended to be a permanent fix or are you planning on
> replacing it with something closer to my version for 3.19?
>
> http://git.kernel.org/cgit/linux/kernel/git/luto/linux.git/commit/?h=userns/fix_magic_nodev&id=bf8b198add82a249d6da4ecf280c30a0865637f6
>
> I still think that the implicit nodev behavior is a bad idea in
> general.

I want to consider your change as part of the larger discussion about
how we take the final step towards allowing fuse and other filesystems
with backing store to be merged in the kernel.

There are actually some other possibilities with s_user_ns in the mix.

The cleanest solution is probably to declare dev_t as well as security
labels values that are interpreted with respect to user namespaces.
Then seeting s_user_ns != &init_user_ns will yield device nodes that
simply don't have a meaning in the kernel.  Which winds up being
effectively the same as an implicit nodev, but without the compatibility
hassle.

But all of that is or should be development.  And what my patch is, is
about getting a simple bug fix that works.

Eric

Re: [CFT][PATCH] mnt: Implicitly add MNT_NODEV on remount when it was implicitly added by mount

[Richard Weinberger]

Eric,

Am 30.11.2014 um 00:05 schrieb Eric W. Biederman:
> 
> Now that remount is properly enforcing the rule that you can't remove
> nodev at least sandstorm.io is breaking when performing a remount.
> 
> It turns out that there is an easy intuitive solution implicitly
> add nodev on remount when nodev was implicitly added on mount.

Is this patch supposed to unbreak libvirt-lxc?
At least 1.2.9 is still broken.

Thanks,
//richard

Re: [CFT][PATCH] mnt: Implicitly add MNT_NODEV on remount when it was implicitly added by mount

[Andy Lutomirski]

On Sun, Nov 30, 2014 at 6:58 AM, Richard Weinberger <richard-/L3Ra7n9ekc@public.gmane.org> wrote:
> Eric,
>
> Am 30.11.2014 um 00:05 schrieb Eric W. Biederman:
>>
>> Now that remount is properly enforcing the rule that you can't remove
>> nodev at least sandstorm.io is breaking when performing a remount.
>>
>> It turns out that there is an easy intuitive solution implicitly
>> add nodev on remount when nodev was implicitly added on mount.
>
> Is this patch supposed to unbreak libvirt-lxc?
> At least 1.2.9 is still broken.
>

Either this patch or my variant of it fixes the libvirt-lxc breakage
that I understand, but IIRC there was some other issue that none of us
figured out at K-S.

--Andy

> Thanks,
> //richard



-- 
Andy Lutomirski
AMA Capital Management, LLC

Re: [CFT][PATCH] mnt: Implicitly add MNT_NODEV on remount when it was implicitly added by mount

[Richard Weinberger]

Am 30.11.2014 um 16:00 schrieb Andy Lutomirski:
> On Sun, Nov 30, 2014 at 6:58 AM, Richard Weinberger <richard-/L3Ra7n9ekc@public.gmane.org> wrote:
>> Eric,
>>
>> Am 30.11.2014 um 00:05 schrieb Eric W. Biederman:
>>>
>>> Now that remount is properly enforcing the rule that you can't remove
>>> nodev at least sandstorm.io is breaking when performing a remount.
>>>
>>> It turns out that there is an easy intuitive solution implicitly
>>> add nodev on remount when nodev was implicitly added on mount.
>>
>> Is this patch supposed to unbreak libvirt-lxc?
>> At least 1.2.9 is still broken.
>>
> 
> Either this patch or my variant of it fixes the libvirt-lxc breakage
> that I understand, but IIRC there was some other issue that none of us
> figured out at K-S.

Currently it fails here:
2014-11-25 22:36:45.295+0000: 1: debug : virFileMakePathHelper:2436 : path=/proc mode=0777
2014-11-25 22:36:45.295+0000: 1: debug : lxcContainerMountBasicFS:918 : Mount proc on /proc type=proc flags=e
2014-11-25 22:36:45.296+0000: 1: debug : lxcContainerMountBasicFS:873 : Processing /proc/sys -> /proc/sys
2014-11-25 22:36:45.296+0000: 1: debug : virFileMakePathHelper:2436 : path=/proc/sys mode=0777
2014-11-25 22:36:45.296+0000: 1: debug : lxcContainerMountBasicFS:918 : Mount /proc/sys on /proc/sys type=(null) flags=1000
2014-11-25 22:36:45.296+0000: 1: error : lxcContainerMountBasicFS:933 : Failed to re-mount /proc/sys on /proc/sys flags=1021: Operation not permitted

Thanks,
//richard

Re: [CFT][PATCH] mnt: Implicitly add MNT_NODEV on remount when it was implicitly added by mount

[Andy Lutomirski]

On Sun, Nov 30, 2014 at 7:16 AM, Richard Weinberger <richard-/L3Ra7n9ekc@public.gmane.org> wrote:
> Am 30.11.2014 um 16:00 schrieb Andy Lutomirski:
>> On Sun, Nov 30, 2014 at 6:58 AM, Richard Weinberger <richard-/L3Ra7n9ekc@public.gmane.org> wrote:
>>> Eric,
>>>
>>> Am 30.11.2014 um 00:05 schrieb Eric W. Biederman:
>>>>
>>>> Now that remount is properly enforcing the rule that you can't remove
>>>> nodev at least sandstorm.io is breaking when performing a remount.
>>>>
>>>> It turns out that there is an easy intuitive solution implicitly
>>>> add nodev on remount when nodev was implicitly added on mount.
>>>
>>> Is this patch supposed to unbreak libvirt-lxc?
>>> At least 1.2.9 is still broken.
>>>
>>
>> Either this patch or my variant of it fixes the libvirt-lxc breakage
>> that I understand, but IIRC there was some other issue that none of us
>> figured out at K-S.
>
> Currently it fails here:
> 2014-11-25 22:36:45.295+0000: 1: debug : virFileMakePathHelper:2436 : path=/proc mode=0777
> 2014-11-25 22:36:45.295+0000: 1: debug : lxcContainerMountBasicFS:918 : Mount proc on /proc type=proc flags=e
> 2014-11-25 22:36:45.296+0000: 1: debug : lxcContainerMountBasicFS:873 : Processing /proc/sys -> /proc/sys
> 2014-11-25 22:36:45.296+0000: 1: debug : virFileMakePathHelper:2436 : path=/proc/sys mode=0777
> 2014-11-25 22:36:45.296+0000: 1: debug : lxcContainerMountBasicFS:918 : Mount /proc/sys on /proc/sys type=(null) flags=1000
> 2014-11-25 22:36:45.296+0000: 1: error : lxcContainerMountBasicFS:933 : Failed to re-mount /proc/sys on /proc/sys flags=1021: Operation not permitted

Any chance you can test that with Eric's patch or mine [1] applied?
If that doesn't work, can you try to catch the failure with strace?

--Andy

[1] https://git.kernel.org/cgit/linux/kernel/git/luto/linux.git/commit/?h=userns/fix_magic_nodev&id=bf8b198add82a249d6da4ecf280c30a0865637f6

>
> Thanks,
> //richard



-- 
Andy Lutomirski
AMA Capital Management, LLC

Re: [CFT][PATCH] mnt: Implicitly add MNT_NODEV on remount when it was implicitly added by mount

[Richard Weinberger]

Am 30.11.2014 um 16:37 schrieb Andy Lutomirski:
> On Sun, Nov 30, 2014 at 7:16 AM, Richard Weinberger <richard-/L3Ra7n9ekc@public.gmane.org> wrote:
>> Am 30.11.2014 um 16:00 schrieb Andy Lutomirski:
>>> On Sun, Nov 30, 2014 at 6:58 AM, Richard Weinberger <richard-/L3Ra7n9ekc@public.gmane.org> wrote:
>>>> Eric,
>>>>
>>>> Am 30.11.2014 um 00:05 schrieb Eric W. Biederman:
>>>>>
>>>>> Now that remount is properly enforcing the rule that you can't remove
>>>>> nodev at least sandstorm.io is breaking when performing a remount.
>>>>>
>>>>> It turns out that there is an easy intuitive solution implicitly
>>>>> add nodev on remount when nodev was implicitly added on mount.
>>>>
>>>> Is this patch supposed to unbreak libvirt-lxc?
>>>> At least 1.2.9 is still broken.
>>>>
>>>
>>> Either this patch or my variant of it fixes the libvirt-lxc breakage
>>> that I understand, but IIRC there was some other issue that none of us
>>> figured out at K-S.
>>
>> Currently it fails here:
>> 2014-11-25 22:36:45.295+0000: 1: debug : virFileMakePathHelper:2436 : path=/proc mode=0777
>> 2014-11-25 22:36:45.295+0000: 1: debug : lxcContainerMountBasicFS:918 : Mount proc on /proc type=proc flags=e
>> 2014-11-25 22:36:45.296+0000: 1: debug : lxcContainerMountBasicFS:873 : Processing /proc/sys -> /proc/sys
>> 2014-11-25 22:36:45.296+0000: 1: debug : virFileMakePathHelper:2436 : path=/proc/sys mode=0777
>> 2014-11-25 22:36:45.296+0000: 1: debug : lxcContainerMountBasicFS:918 : Mount /proc/sys on /proc/sys type=(null) flags=1000
>> 2014-11-25 22:36:45.296+0000: 1: error : lxcContainerMountBasicFS:933 : Failed to re-mount /proc/sys on /proc/sys flags=1021: Operation not permitted
> 
> Any chance you can test that with Eric's patch or mine [1] applied?
> If that doesn't work, can you try to catch the failure with strace?

With your patch applied on top of Linus's tree as of today libvirt-lxc works fine again. :)

Thanks,
//richard

Re: [CFT][PATCH] mnt: Implicitly add MNT_NODEV on remount when it was implicitly added by mount

[Eric W. Biederman]

Richard Weinberger <richard-/L3Ra7n9ekc@public.gmane.org> writes:

> Am 30.11.2014 um 16:37 schrieb Andy Lutomirski:
>> On Sun, Nov 30, 2014 at 7:16 AM, Richard Weinberger <richard-/L3Ra7n9ekc@public.gmane.org> wrote:
>>> Am 30.11.2014 um 16:00 schrieb Andy Lutomirski:
>>>> On Sun, Nov 30, 2014 at 6:58 AM, Richard Weinberger <richard-/L3Ra7n9ekc@public.gmane.org> wrote:
>>>>> Eric,
>>>>>
>>>>> Am 30.11.2014 um 00:05 schrieb Eric W. Biederman:
>>>>>>
>>>>>> Now that remount is properly enforcing the rule that you can't remove
>>>>>> nodev at least sandstorm.io is breaking when performing a remount.
>>>>>>
>>>>>> It turns out that there is an easy intuitive solution implicitly
>>>>>> add nodev on remount when nodev was implicitly added on mount.
>>>>>
>>>>> Is this patch supposed to unbreak libvirt-lxc?
>>>>> At least 1.2.9 is still broken.
>>>>>
>>>>
>>>> Either this patch or my variant of it fixes the libvirt-lxc breakage
>>>> that I understand, but IIRC there was some other issue that none of us
>>>> figured out at K-S.
>>>
>>> Currently it fails here:
>>> 2014-11-25 22:36:45.295+0000: 1: debug : virFileMakePathHelper:2436 : path=/proc mode=0777
>>> 2014-11-25 22:36:45.295+0000: 1: debug : lxcContainerMountBasicFS:918 : Mount proc on /proc type=proc flags=e
>>> 2014-11-25 22:36:45.296+0000: 1: debug : lxcContainerMountBasicFS:873 : Processing /proc/sys -> /proc/sys
>>> 2014-11-25 22:36:45.296+0000: 1: debug : virFileMakePathHelper:2436 : path=/proc/sys mode=0777
>>> 2014-11-25 22:36:45.296+0000: 1: debug : lxcContainerMountBasicFS:918 : Mount /proc/sys on /proc/sys type=(null) flags=1000
>>> 2014-11-25 22:36:45.296+0000: 1: error : lxcContainerMountBasicFS:933 : Failed to re-mount /proc/sys on /proc/sys flags=1021: Operation not permitted
>> 
>> Any chance you can test that with Eric's patch or mine [1] applied?
>> If that doesn't work, can you try to catch the failure with strace?
>
> With your patch applied on top of Linus's tree as of today libvirt-lxc works fine again. :)

*Scratches head*

Did you really have my latest patch applied?

Andy's patch implies a change of policy that I really don't want to
deploy as a bug fix.

Eric

Re: [CFT][PATCH] mnt: Implicitly add MNT_NODEV on remount when it was implicitly added by mount

[Richard Weinberger]

Am 30.11.2014 um 19:35 schrieb Eric W. Biederman:
> Richard Weinberger <richard-/L3Ra7n9ekc@public.gmane.org> writes:
> 
>> Am 30.11.2014 um 16:37 schrieb Andy Lutomirski:
>>> On Sun, Nov 30, 2014 at 7:16 AM, Richard Weinberger <richard-/L3Ra7n9ekc@public.gmane.org> wrote:
>>>> Am 30.11.2014 um 16:00 schrieb Andy Lutomirski:
>>>>> On Sun, Nov 30, 2014 at 6:58 AM, Richard Weinberger <richard-/L3Ra7n9ekc@public.gmane.org> wrote:
>>>>>> Eric,
>>>>>>
>>>>>> Am 30.11.2014 um 00:05 schrieb Eric W. Biederman:
>>>>>>>
>>>>>>> Now that remount is properly enforcing the rule that you can't remove
>>>>>>> nodev at least sandstorm.io is breaking when performing a remount.
>>>>>>>
>>>>>>> It turns out that there is an easy intuitive solution implicitly
>>>>>>> add nodev on remount when nodev was implicitly added on mount.
>>>>>>
>>>>>> Is this patch supposed to unbreak libvirt-lxc?
>>>>>> At least 1.2.9 is still broken.
>>>>>>
>>>>>
>>>>> Either this patch or my variant of it fixes the libvirt-lxc breakage
>>>>> that I understand, but IIRC there was some other issue that none of us
>>>>> figured out at K-S.
>>>>
>>>> Currently it fails here:
>>>> 2014-11-25 22:36:45.295+0000: 1: debug : virFileMakePathHelper:2436 : path=/proc mode=0777
>>>> 2014-11-25 22:36:45.295+0000: 1: debug : lxcContainerMountBasicFS:918 : Mount proc on /proc type=proc flags=e
>>>> 2014-11-25 22:36:45.296+0000: 1: debug : lxcContainerMountBasicFS:873 : Processing /proc/sys -> /proc/sys
>>>> 2014-11-25 22:36:45.296+0000: 1: debug : virFileMakePathHelper:2436 : path=/proc/sys mode=0777
>>>> 2014-11-25 22:36:45.296+0000: 1: debug : lxcContainerMountBasicFS:918 : Mount /proc/sys on /proc/sys type=(null) flags=1000
>>>> 2014-11-25 22:36:45.296+0000: 1: error : lxcContainerMountBasicFS:933 : Failed to re-mount /proc/sys on /proc/sys flags=1021: Operation not permitted
>>>
>>> Any chance you can test that with Eric's patch or mine [1] applied?
>>> If that doesn't work, can you try to catch the failure with strace?
>>
>> With your patch applied on top of Linus's tree as of today libvirt-lxc works fine again. :)
> 
> *Scratches head*
> 
> Did you really have my latest patch applied?
> 
> Andy's patch implies a change of policy that I really don't want to
> deploy as a bug fix.

Hmm, let me double check this tomorrow with a fresh brain.
Maybe I got hit by another issue while testing your patch.
Currently I'm fighting against three libvirt-lxc issues in parallel. :-\

Thanks,
//richard

Re: [CFT][PATCH] mnt: Implicitly add MNT_NODEV on remount when it was implicitly added by mount

[Eric W. Biederman]

Richard Weinberger <richard-/L3Ra7n9ekc@public.gmane.org> writes:

> Am 30.11.2014 um 19:35 schrieb Eric W. Biederman:
>> Richard Weinberger <richard-/L3Ra7n9ekc@public.gmane.org> writes:
>> 
>>> Am 30.11.2014 um 16:37 schrieb Andy Lutomirski:
>>>> On Sun, Nov 30, 2014 at 7:16 AM, Richard Weinberger <richard-/L3Ra7n9ekc@public.gmane.org> wrote:
>>>>> Am 30.11.2014 um 16:00 schrieb Andy Lutomirski:
>>>>>> On Sun, Nov 30, 2014 at 6:58 AM, Richard Weinberger <richard-/L3Ra7n9ekc@public.gmane.org> wrote:
>>>>>>> Eric,
>>>>>>>
>>>>>>> Am 30.11.2014 um 00:05 schrieb Eric W. Biederman:
>>>>>>>>
>>>>>>>> Now that remount is properly enforcing the rule that you can't remove
>>>>>>>> nodev at least sandstorm.io is breaking when performing a remount.
>>>>>>>>
>>>>>>>> It turns out that there is an easy intuitive solution implicitly
>>>>>>>> add nodev on remount when nodev was implicitly added on mount.
>>>>>>>
>>>>>>> Is this patch supposed to unbreak libvirt-lxc?
>>>>>>> At least 1.2.9 is still broken.
>>>>>>>
>>>>>>
>>>>>> Either this patch or my variant of it fixes the libvirt-lxc breakage
>>>>>> that I understand, but IIRC there was some other issue that none of us
>>>>>> figured out at K-S.
>>>>>
>>>>> Currently it fails here:
>>>>> 2014-11-25 22:36:45.295+0000: 1: debug : virFileMakePathHelper:2436 : path=/proc mode=0777
>>>>> 2014-11-25 22:36:45.295+0000: 1: debug : lxcContainerMountBasicFS:918 : Mount proc on /proc type=proc flags=e
>>>>> 2014-11-25 22:36:45.296+0000: 1: debug : lxcContainerMountBasicFS:873 : Processing /proc/sys -> /proc/sys
>>>>> 2014-11-25 22:36:45.296+0000: 1: debug : virFileMakePathHelper:2436 : path=/proc/sys mode=0777
>>>>> 2014-11-25 22:36:45.296+0000: 1: debug : lxcContainerMountBasicFS:918 : Mount /proc/sys on /proc/sys type=(null) flags=1000
>>>>> 2014-11-25 22:36:45.296+0000: 1: error : lxcContainerMountBasicFS:933 : Failed to re-mount /proc/sys on /proc/sys flags=1021: Operation not permitted
>>>>
>>>> Any chance you can test that with Eric's patch or mine [1] applied?
>>>> If that doesn't work, can you try to catch the failure with strace?
>>>
>>> With your patch applied on top of Linus's tree as of today libvirt-lxc works fine again. :)
>> 
>> *Scratches head*
>> 
>> Did you really have my latest patch applied?
>> 
>> Andy's patch implies a change of policy that I really don't want to
>> deploy as a bug fix.
>
> Hmm, let me double check this tomorrow with a fresh brain.
> Maybe I got hit by another issue while testing your patch.
> Currently I'm fighting against three libvirt-lxc issues in parallel. :-\

Please do.  I just reran through my regression tests that explore this
issue rather throughly and all of my remount test cases are passing.  So
if things are truly failing I want to understand what is going on, and
add to my regression tests.

I should have done that sooner of course but I am still paging back in
after being distracted with the other things in life.

Eric

Re: [CFT][PATCH] mnt: Implicitly add MNT_NODEV on remount when it was implicitly added by mount

[Richard Weinberger]

Am 01.12.2014 um 02:29 schrieb Eric W. Biederman:
>>>>> Any chance you can test that with Eric's patch or mine [1] applied?
>>>>> If that doesn't work, can you try to catch the failure with strace?
>>>>
>>>> With your patch applied on top of Linus's tree as of today libvirt-lxc works fine again. :)
>>>
>>> *Scratches head*
>>>
>>> Did you really have my latest patch applied?
>>>
>>> Andy's patch implies a change of policy that I really don't want to
>>> deploy as a bug fix.
>>
>> Hmm, let me double check this tomorrow with a fresh brain.
>> Maybe I got hit by another issue while testing your patch.
>> Currently I'm fighting against three libvirt-lxc issues in parallel. :-\
> 
> Please do.  I just reran through my regression tests that explore this
> issue rather throughly and all of my remount test cases are passing.  So
> if things are truly failing I want to understand what is going on, and
> add to my regression tests.
> 
> I should have done that sooner of course but I am still paging back in
> after being distracted with the other things in life.

I can confirm that your patch "mnt: Implicitly add MNT_NODEV on remount as we do on mount"
unbreaks libvirt-lxc too. :-)
Sorry for the false negative.

Thanks,
//richard

Re: [CFT][PATCH] mnt: Implicitly add MNT_NODEV on remount when it was implicitly added by mount

[Eric W. Biederman]

Richard Weinberger <richard-/L3Ra7n9ekc@public.gmane.org> writes:

> Am 01.12.2014 um 02:29 schrieb Eric W. Biederman:
>>>>>> Any chance you can test that with Eric's patch or mine [1] applied?
>>>>>> If that doesn't work, can you try to catch the failure with strace?
>>>>>
>>>>> With your patch applied on top of Linus's tree as of today libvirt-lxc works fine again. :)
>>>>
>>>> *Scratches head*
>>>>
>>>> Did you really have my latest patch applied?
>>>>
>>>> Andy's patch implies a change of policy that I really don't want to
>>>> deploy as a bug fix.
>>>
>>> Hmm, let me double check this tomorrow with a fresh brain.
>>> Maybe I got hit by another issue while testing your patch.
>>> Currently I'm fighting against three libvirt-lxc issues in parallel. :-\
>> 
>> Please do.  I just reran through my regression tests that explore this
>> issue rather throughly and all of my remount test cases are passing.  So
>> if things are truly failing I want to understand what is going on, and
>> add to my regression tests.
>> 
>> I should have done that sooner of course but I am still paging back in
>> after being distracted with the other things in life.
>
> I can confirm that your patch "mnt: Implicitly add MNT_NODEV on remount as we do on mount"
> unbreaks libvirt-lxc too. :-)
> Sorry for the false negative.

Thanks I will add your Tested-by.

Eric

Re: [CFT][PATCH] mnt: Implicitly add MNT_NODEV on remount when it was implicitly added by mount

[joeyli]

Hi Eric, 

On Tue, Dec 02, 2014 at 03:53:34AM -0600, Eric W. Biederman wrote:
> Richard Weinberger <richard-/L3Ra7n9ekc@public.gmane.org> writes:
> 
> > Am 01.12.2014 um 02:29 schrieb Eric W. Biederman:
> >>>>>> Any chance you can test that with Eric's patch or mine [1] applied?
> >>>>>> If that doesn't work, can you try to catch the failure with strace?
> >>>>>
> >>>>> With your patch applied on top of Linus's tree as of today libvirt-lxc works fine again. :)
> >>>>
> >>>> *Scratches head*
> >>>>
> >>>> Did you really have my latest patch applied?
> >>>>
> >>>> Andy's patch implies a change of policy that I really don't want to
> >>>> deploy as a bug fix.
> >>>
> >>> Hmm, let me double check this tomorrow with a fresh brain.
> >>> Maybe I got hit by another issue while testing your patch.
> >>> Currently I'm fighting against three libvirt-lxc issues in parallel. :-\
> >> 
> >> Please do.  I just reran through my regression tests that explore this
> >> issue rather throughly and all of my remount test cases are passing.  So
> >> if things are truly failing I want to understand what is going on, and
> >> add to my regression tests.
> >> 
> >> I should have done that sooner of course but I am still paging back in
> >> after being distracted with the other things in life.
> >
> > I can confirm that your patch "mnt: Implicitly add MNT_NODEV on remount as we do on mount"
> > unbreaks libvirt-lxc too. :-)
> > Sorry for the false negative.
> 
> Thanks I will add your Tested-by.
> 
> Eric

Cedric help to test my kernel that included your patch. Please feel free to
add:

Tested-by: Cedric Bosdonnat <cbosdonnat-IBi9RG/b67k@public.gmane.org>


Regards
Joey Lee

Re: What's the status of 87b47932 patch - mnt: Implicitly add MNT_NODEV on remount as we do on mount

[joeyli]

Hi Eric, 

On Sat, Nov 29, 2014 at 05:04:03PM -0600, Eric W. Biederman wrote:
> joeyli <jlee-IBi9RG/b67k@public.gmane.org> writes:
> 
> > Hi Eric, 
> >
> > Sorry for bother you. I saw your patch:
> > 	mnt: Implicitly add MNT_NODEV on remount as we do on mount
> >
> > Already commited in linux-next:
> > https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/commit/fs/namespace.c?id=87b47932f40a11280584bce260cbdb3b5f9e8b7d
> >
> > But, I didn't see this patch show in v3.18-rc kernel in Linus's git tree.
> > What's the status of 87b47932 patch? Does there have regression cases it
> > could not be merged to v3.18 kernel?
> 
> The patch actually breaks remounting filesystems that did not have
> MNT_NODEV set when theny were mounted.
> 
> The primary issue is that the bug hit at a very inopportune time in my
> life (just before kernel summit) after which I had a vacation planned
> and after that I had some serious job hunting and moving to do. 
> 
> Now I am busily trying to catch up on my queue and these long delayed
> bug fixes are the next issue.
> 
> If folks can review/test the current version of the patch (to follow in
> a moment) I would appreciate it.  Based on previous testing unless I
> have a typo what I expect to see is:
> lxc  - b0rked.  The old versions of lxc must be broken to fix the
>        security issue.
> libvirt-lxc - fixed.
> Andy's thing - fixed.
> 
> Any comments on the next user namespace breaking security fix that is
> being finalized would also be appreciated.
> 
> Eric

Thanks for your quick response and information about your patches.

Joey Lee