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]
Message-Id: <E1P3n00-0000rf-ID@pomaz-ex.szeredi.hu>
Date:	Thu, 07 Oct 2010 11:42:52 +0200
From:	Miklos Szeredi <miklos@...redi.hu>
To:	Valerie Aurora <vaurora@...hat.com>
CC:	miklos@...redi.hu, linuxram@...ibm.com, mszeredi2@...il.com,
	viro@...iv.linux.org.uk, hch@...radead.org, agruen@...e.de,
	npiggin@...nel.dk, linux-kernel@...r.kernel.org,
	linux-fsdevel@...r.kernel.org
Subject: Re: [PATCH 01/34] VFS: Make clone_mnt() and copy_tree() return error codes

On Wed, 6 Oct 2010, Valerie Aurora wrote:
> On Fri, Oct 01, 2010 at 11:12:48AM +0200, Szeredi Miklos wrote:
> > On Fri, Oct 1, 2010 at 3:58 AM, Ram Pai <linuxram@...ibm.com> wrote:
> > > > > > > @@ -1212,11 +1216,12 @@ struct vfsmount *copy_tree(struct vfsmount *mnt, struct dentry *dentry,
> > > > > > > ? ? ? ? struct path path;
> > > > > > >
> > > > > > > ? ? ? ? if (!(flag & CL_COPY_ALL) && IS_MNT_UNBINDABLE(mnt))
> > > > > > > - ? ? ? ? ? ? ? return NULL;
> > > > > > > + ? ? ? ? ? ? ? return ERR_PTR(-EINVAL);
> > > > >
> > > > > Ram, do you remember how this worked?
> > > >
> > > > Oops. That should be a OR condition. there is one other check in that
> > > > function that should also be a OR condition.
> > >
> > > I may be wrong here. Can't exactly recollect what CL_COPY_ALL flag means. Al Viro
> > > might remember? ?If CL_COPY_ALL means, to clone everything irrespective of any other
> > > flags, then the above code seems right.
> > 
> > CL_COPY_ALL means clone the mount despite MNT_UNBINDABLE.  It is used
> > for cloning the whole namespace and for collect_mounts(), both of
> > which ignore MNT_UNBINDABLE.
> > 
> > Of the two remaining callers of copy_tree() do_loopback already checks
> > MNT_UNBINDABLE on the root of the tree to be copied.
> 
> I reviewed and tested and agree.
> 
> But I don't think this change should go into stable.  It doesn't fix
> any existing bug and I don't like perturbing the code in stable for a
> code cleanup.

Right.

> > So that leaves the one in pnode.c.   That one will be called when
> > attaching a new mount or mount tree.  If the root of that tree is
> > unbindable then the propagation will fail with -ENOMEM which is wrong,
> > it should simply skip the whole tree and not try to propagate.   Calls
> 
> Not try to propagate - and return an error?  Or succeed and ignore?

I thought succeed and ignore is the right answer, but I'm not sure
now.

> > which result in propagation are  do_loopback, do_move_mount and
> > do_add_mount.  Of this do_loopback and do_move_mount already check for
> > MNT_UNBINDABLE, do_add_mount doesn't check, but should probably just
> > mask out MNT_UNBINDABLE.
> 
> Hm, if we stop trusting callers of do_add_mount(), we should probably
> do a lot more than just mask this out.  Interestingly, most out-of-VFS
> callers just seem to add MNT_SHRINKABLE, maybe we should export
> do_add_shrinkable() instead or something like that?
> 
> > So in the end that check in copy_tree() should never actually trigger
> > and can be turned into a WARN_ON
> 
> WARN_ON() makes sense.
> 
> > Additionally the propagation code should perhaps be more defensive and
> > skip MNT_UNBINDABLE source mounts.
> 
> Maybe WARN_ON() here too?

Yes, I think so.

Thanks,
Miklos
--
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ