bug in slnprintf

[Luke Kenneth Casson Leighton]

On Tue, 1 Dec 1998, Jeremy Allison wrote:

> Luke Kenneth Casson Leighton wrote:
> > 
> > it doesn't null-terminate correctly, 
> 
> I take it you mean slprintf not slnprintf.
> 
> > or initialise the whole of the buffer
> > to zero before use.  
> 
> It's not supposed to do that.
> 
> > %s\\%s with two string-pairs, one pair shorter than
> > the other, shows up the previous pair:
> > 
> > BUILTIN\Administrator
> > TEST\rootdministrator
> > 
> > in rpcclient lookupsids command, for example.
> 
> What length are you passing in that call.

sizeof(fstring) - 1.

> The slprintf code *definately* null terminates
> as far as I can tell from the code.

try rpcclient -S nt_server -U%
then lsaquery
then lookupsids S-1-5-32-544 1001

or any other two sids where the first response is longer than the second.


> It calls vslprintf which is defined as :
> 
> -----------cut here--------------------------
> /* this is like vsnprintf but the 'n' limit does not include
>    the terminating null. So if you have a 1024 byte buffer then
>    pass 1023 for n */
> int vslprintf(char *str, int n, char *format, va_list ap)
> {
>     int ret = vsnprintf(str, n, format, ap);
>     if (ret > n || ret < 0) {
>         str[n] = 0;
>         return -1;
>     }
>     str[ret] = 0;
>     return ret;
> }
> ---------------------end--------------------
> 
> Maybe you have a broken vsnprintf that is not returning
> the correct length ? What does your configure
> output say about where the vsnprintf comes from ?

it says "yes" to vsnprintf
 
> Are you still using slackware ?

yep :)  it'd take me a couple of days to get back to where i am, with a
reinstall of a different os.

> Does the libc5 vsnprintf
> return the correct length ?

dunno.  i'll put some checks in.