[Samba] smbclient: Tar create to stdout produces a broken tarball

[Noel Power]

On 02/05/2022 16:23, Marc Leuser via samba wrote:
> Hi everybody,
>
> when running "smbclient -Tc -" to get the tarball to stdout, a debug 
> message that should be sent to stderr is sent to stdout instead, which 
> results in a broken archive. I'm testing version 4.15.2 on Alpine and 
> have two commands to reproduce this behaviour:
>
> /usr/bin/smbclient \\\\servername\\C\$ -U Username -E -d 1 -c tarmode\ 
> full -mSMB3 -Tc - \\something > smbdump.tar
> PASSWD=passwordhere /usr/bin/smbclient \\\\servername\\C\$ -U Username 
> -E -d 1 -c tarmode\ full -mSMB3 -Tc - \\something > smbdump.tar
>
> The first one puts "Password for [MYGROUP\Administrator]:" at the 
> beginning of the tarball,

In my tests this happens in 4.12.2, 4.15.5, 4.16.x etc. And ... that is 
to be expected as afaics the prompt for the username is and has always 
has been written to stdout. Not sure if I did something wrong or 
misunderstood

Also in my tests for the above I have to type in the password (but of 
course this is not that obvious since the prompt for the password has 
been outputted to smbdump.tar. Again this is what I see in all versions, 
not just in 4.15.5.

But... for all versions what I see is if you specify the password either 
on the command line with '-Uusername%password' or even with 
'PASSWD=password' as above then it seems you get a usable archive

> the second one puts "tarmode is now full, system, hidden, noreset, 
> noverbose" and a newline (0x0A). Initially i thought it's related to a 
> specific message, but it looks like there are at least two of them. 
> Interestingly, when i run the same commands with debug levels 0-10, 
> the resulting files are the same. So it appears that it's also not 
> just "the first debug message that gets printed".

In this case I do see that the archive produced in versions >= 4.15.0 
has the cmd output status appended to end of the archive file. But again 
the tarball isn't broken or at least on my system it isn't, the end of a 
tar archive file is marked by two 512-byte blocks filled with binary 
zeros, the content appended after that is ignored. But of course I don't 
think we should be writing there :-)

>
> Since the environment i'm encountering this bug in is Docker-based, i 
> was able to quickly hop between versions and was able to narrow the 
> scope down to two versions of smbclient i had available. 4.12.15 is 
> still working, 4.14.5 has the breakage in it. Another observation is 
> that the working version prints several messages to stderr which 
> appear on the console, while the broken versions seem to print nothing 
> to stderr at all. I've tried sifting through the source code and 
> revisions but now i'm a bit lost. The only thing i found was that 
> there seems to be no test for this specific case, which explains why 
> it wasn't spotted.
>
> Can someone else confirm this bug?

Basically it seems the '-E' flag is not working, from smbclient --help

   -E, --stderr            Write messages to stderr instead of stdout

> And can somebody with a better overview of the codebase maybe spot why 
> it's there?
>
the change in behaviour was introduced as part of some work to use newer 
command parser code, I opened 
https://bugzilla.samba.org/show_bug.cgi?id=15075 for this and will 
propose a fix

Noel