coding volunteers needed for msrpc server-side API conversion

[Elrond]

On Fri, Jan 28, 2000 at 06:39:46AM +1100, Luke Kenneth Casson Leighton wrote:
> > In cli_*.c we do:
> > 
> > xxx_xxx(const foo in, foo **out)
> > 	xxx_make_q_xxx(in) /* this one dups all the neccessary things */
> 
> elrond,
> k
> thi is not acceptable for the SPOOLSS functions, which pass in a
> stupid-wasted buffer as an [in out] parameter.

Well, that sounds like spoolss isn't doing _any_ dynamic
memory, so there isn't really a conflict / problem here.

Just don't use any malloc/free, and all is fine.

All my arguments are for dynamic memory only. For the rest,
there's no need to dup() things.


> the buffer size could potentiallly be several megabytes in size.  NT has a
> hard-limit of 5mb on dce/rpc data and a hard-limit of unknown size in
> SPOOLLSS but they got it wrong.  [if you send a request with 1mb of
> spoolss data you will terminate spoolss.exe].

That pretty sounds like DoS in nt... are they aware of
that / is anyone doing anything about it?

(Okay... on the other side... It's nt... we're used to it
having security-issues)

> anyway, the upshot is that it's not really ok to dup() [in] and [in out]
> parameters.

I think, it's okay, to dup() dynamic things.

in_out-params are a problem... But I currently can't realy
see, how they can be dynamic.


    Elrond