[PATCHES] MS-PAR rpcclient

[Jeremy Allison]

On Wed, Nov 23, 2016 at 04:26:17PM +0100, Günther Deschner wrote:
> On 23/11/16 16:14, Andreas Schneider wrote:
> > On Wednesday, 23 November 2016 16:04:47 CET Günther Deschner wrote:
> >> Hi,
> >>
> >> attached some patches to create a basic iremotewinspool rpcclient tool.
> >>
> >> Note that the object_uuid is set directly in the
> >> dcerpc_binding_handle_call() unlike our smbtorture4 client
> >> iremotewinspool code where we set the interface specific object_uuid via
> >> the binding handle (passing down the full binding in s3 rpc_client code
> >> would require some major restructuring which we would like to avoid for
> >> now).
> > 
> > a) We have 2016, see copyright :)
> 
> Yeah but the code was in fact written in 2013.
> 
> > b) Instead of Async* I would prefered if calls would start with winspool 
> > instead. This make it clear we use the winspool protocol here. We have tab 
> > completion in rpcclient and this would make it easier to find a winspool 
> > comand.
> 
> Done, I added a winspool_ prefix now. Better?

I know this is now in the build, but do we need
any integer wrap protections in the librpc/ndr/ndr_cab.c
code ?

I'm thinking of things like:

ndr_size_cab_file()
...
        for (i = 0; i < r->cfheader.cFiles; i++) {
                size += ndr_size_CFFILE(&r->cffiles[i], 0);
        }

        /* data */
        for (i = 0; i < ndr_count_cfdata(r); i++) {
                size += 8 + r->cfdata[i].cbData;
        }

size might need integer wrap protection here.

ndr_count_cfdata()
...
        for (i = 0; i < r->cfheader.cFolders; i++) {
                count += r->cffolders[i].cCFData;
        }

Same there.

Pure paranoia of course, but these days I find
paranoia is usually justified :-).

What do you think ? If you agree I can code it
up for you to review.

Cheers,

	Jeremy.