linux-kernel - Re: [PATCH 05/40] staging/lustre: validate open handle cookies

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: <20131116195001.GA9308@kroah.com>
Date:	Sat, 16 Nov 2013 11:50:01 -0800
From:	Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To:	"Dilger, Andreas" <andreas.dilger@...el.com>
Cc:	Peng Tao <bergwolf@...il.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"Hammond, John" <john.hammond@...el.com>
Subject: Re: [PATCH 05/40] staging/lustre: validate open handle cookies

On Sat, Nov 16, 2013 at 11:20:37AM +0000, Dilger, Andreas wrote:
> On 2013/11/14 9:13 PM, "Greg Kroah-Hartman" <gregkh@...uxfoundation.org>
> wrote:
> 
> >On Fri, Nov 15, 2013 at 12:13:07AM +0800, Peng Tao wrote:
> >> From: "John L. Hammond" <john.hammond@...el.com>
> >> 
> >> Add a const void *h_owner member to struct portals_handle. Add a const
> >> void *owner parameter to class_handle2object() which must be matched
> >> by the h_owner member of the handle in addition to the cookie.
> >
> >Ick ick ick.
> >
> >NEVER use a void pointer if you can help it, and for a "handle", never.
> >This isn't other operating systems, sorry.  We know what types our
> >pointers to structures are, use them, so that the compiler can catch our
> >problems, and don't try to cheat by using void *.
> 
> The portals_handle is used as a generic type for objects referenced over
> the network, like a file handle.  The "owner" parameter is just used as
> an extra check that the cookie passed from the client is actually a
> valid value for the code in which it is being used (e.g. metadata or
> data object).  It isn't actually dereferenced by anything, it is just
> like a magic value.

Then make it an explicit type, not a void *.

> >> Adjust
> >> the callers of class_handle2object() accordingly, using NULL as the
> >> argument to the owner parameter, except in the case of
> >> mdt_handle2mfd() where we add an explicit mdt_export_data parameter
> >> which we use as the owner when searching for a MFD. When allocating a
> >> new MFD, pass a pointer to the mdt_export_data into mdt_mfd_new() and
> >> store it in h_owner. This allows the MDT to validate that the client
> >> has not sent the wrong open handle cookie, or sent the right cookie to
> >> the wrong MDT.
> >
> >This changelog entry doesn't even match up with the code below.  ALl
> >callers of class_handle2object are passing NULL here, which makes this
> >patch pretty pointless, right?
> 
> As Tao wrote, this is the patch summary that matches what was committed
> in our own tree and in this case mostly describes the changes made on the
> server.  Keeping the same commits and comments in both trees makes it
> easier to keep the code in sync.

Ok, but as it is, this patch does nothing to the client code, so how can
I accept it?  A function that is only ever called with NULL as an option
is ripe for cleanup in my eyes.

> >And that's a _very_ generic global symbol name, please don't do that, it
> >needs to be "lustre_*" at the front to even expect it to be acceptable.
> 
> There's already something else called a "lustre_handle", so what about
> obdclass_handle2object(), since this is in the obdclass module?

I don't care, but make it unique to the lustre subsystem somehow.
Haveing it start with "class_" looks like it belongs to the driver core
which isn't ok.

thanks,

greg k-h
--
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/