samba - May 2022 - smbclient: Tar create to stdout produces a broken tarball

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, 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".

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? And can somebody with a better 
overview of the codebase maybe spot why it's there?

Best Regards
Marc Leuser

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