samba - Aug 2017 - FreeBSD samba server returns nt_status_acces_denied when DosStream xattr larger than 64KB

I wrote a powershell script on a windows computer to write an ADS on a file
on a FreeBSD server with streams_xattr enabled. If it's smaller than 64KB,
it succeeds. If it's larger than 64KB, I get an "access denied
message" and
powershell crashes. FreeBSD actually allows creation of large extended
attributes (at least on ZFS volumes). I've personally added ones of up to
3MB in size, but have never actually tested the limits.

For the fun of it I decided to run the following command from the CLI in
FreeBSD "cat <large file> | setextattr -i user
'DosStream.User.SecretStream:$DATA' test.txt" This had the effect
of
creating something that samba should recognize as an ADS that is
arbitrarily large.

If I run the following powershell command from a Windows client "Get-Item
-Path .\test.txt -stream *", I do not see the ADS listed unless it is
smaller than 64KB. When it is larger than it, and I have logging ratcheted
up I get logs like below. Out of curiousity, does Samba not support large
ADS? Do you have any pointers on how to maybe coax Samba into letting me
abuse xattrs better?

[2017/08/02 10:55:51.475689, 10, pid=43437, effective(21112, 20513),
real(0, 0), class=vfs]
../source3/modules/vfs_streams_xattr.c:753(walk_xattr_streams)
  Could not get ea user.DosStream.User.SecretStream:$DATA for file
test2.txt: NT_STATUS_ACCESS_DENIED
[2017/08/02 10:55:51.475753, 10, pid=43437, effective(21112, 20513),
real(0, 0)] ../source3/smbd/trans2.c:4685(marshall_stream_info)
  refusing to overflow reply at stream 0
[2017/08/02 10:55:51.475771, 10, pid=43437, effective(21112, 20513),
real(0, 0)] ../source3/smbd/trans2.c:5358(smbd_do_qfilepathinfo)
  marshall_stream_info failed: STATUS_BUFFER_OVERFLOW
[2017/08/02 10:55:51.475789,  3, pid=43437, effective(21112, 20513),
real(0, 0)] ../source3/smbd/smb2_server.c:3097(smbd_smb2_request_error_ex)
  smbd_smb2_request_error_ex: smbd_smb2_request_error_ex: idx[5]
status[STATUS_BUFFER_OVERFLOW] || at ../source3/smbd/smb2_getinfo.c:154
[2017/08/02 10:55:51.475807, 10, pid=43437, effective(21112, 20513),
real(0, 0)] ../source3/smbd/smb2_server.c:2988(smbd_smb2_request_done_ex)
  smbd_smb2_request_done_ex: idx[5] status[STATUS_BUFFER_OVERFLOW] body[8]
dyn[yes:1] at ../source3/smbd/smb2_server.c:3145

On Wed, Aug 02, 2017 at 11:21:56AM -0500, Andrew Walker via samba
wrote:
> I wrote a powershell script on a windows computer to write an ADS on a file
> on a FreeBSD server with streams_xattr enabled. If it's smaller than
64KB,
> it succeeds. If it's larger than 64KB, I get an "access denied
message" and
> powershell crashes. FreeBSD actually allows creation of large extended
> attributes (at least on ZFS volumes). I've personally added ones of up
to
> 3MB in size, but have never actually tested the limits.
oh, really? Does it these day support the POSIX file IO API on xattrs like
Solaris does? It didn't the last time I checked.
> For the fun of it I decided to run the following command from the CLI in
> FreeBSD "cat <large file> | setextattr -i user
> 'DosStream.User.SecretStream:$DATA' test.txt" This had the
effect of
> creating something that samba should recognize as an ADS that is
> arbitrarily large.
> 
> If I run the following powershell command from a Windows client
"Get-Item
> -Path .\test.txt -stream *", I do not see the ADS listed unless it is
> smaller than 64KB. When it is larger than it, and I have logging ratcheted
> up I get logs like below. Out of curiousity, does Samba not support large
> ADS? Do you have any pointers on how to maybe coax Samba into letting me
> abuse xattrs better?
Yeah, iirc a built in buffer-size limit. We don't expect xattrs to be much
larger, as no fs on Linux supports xattrs larger then iirc 64 KB.

If you feel like it, you could write a VFS module that adds better support for
this on FreeBSD, but what is the use case?

-slow

>
> If you feel like it, you could write a VFS module that adds better support
> for
> this on FreeBSD, but what is the use case?
>
I've noticed in online forums that occasionally home NAS users will for
various reasons have streams_xattr enabled and receive 'access denied'
errors when trying to write files with large alternate datastreams. These
are typically on media files (most commonly I've seen them on .avi files),
but I haven't looked closely at them. I'd say the large ADS is either
metadata or malware :-)

The issue doesn't come up frequently because most people don't enable
streams_xattr (though this may change as more home users or NAS vendors
start enabling vfs_fruit + streams_xattr).

I was just curious about whether the behavior is configurable, and now the
curiosity is satisfied. :-)