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

[Stefan G. Weichinger]

Am 24.05.22 um 10:49 schrieb Noel Power via samba:
> 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?

I am seeing issues with smbclient and tar when run within the Amanda 
Backup system.

Maybe that corresponds to the bug mentioned here, I just start to test 
things and compare.

using smbclient-4.16.1 currently and I get tarballs with many "Skipping 
to next header" lines.

Amanda basically runs something like:

% /usr/bin/smbclient //server/share -b 0 -N -E -m SMB2 -d 0 -c 'tarmode 
full reset hidden system; tarmode noverbose; tar c - ' -U username -P 
password > out.tar