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

>
> 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. :-)

It's also interesting to note that ReFS in windows has a 128KB limit on the
size of alternate data streams.

When you try to write an overly large stream, the ReFS-backed server
replies with "NT_STATUS_FILE_SYSTEM_LIMITATION" (0xc0000427) rather
than
"access denied". The windows client handles this more gracefully than
a
simple access denied message. It allows users to skip the file / doesn't
pop up a password prompt.

On Mon, Aug 7, 2017 at 6:15 AM, Andrew Walker <walker.aj325 at gmail.com>
wrote:
> 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. :-)
>

On Mon, Aug 07, 2017 at 08:26:22PM -0500, Andrew Walker via samba
wrote:
> It's also interesting to note that ReFS in windows has a 128KB limit on
the
> size of alternate data streams.
> 
> When you try to write an overly large stream, the ReFS-backed server
> replies with "NT_STATUS_FILE_SYSTEM_LIMITATION" (0xc0000427)
rather than
> "access denied". The windows client handles this more gracefully
than a
> simple access denied message. It allows users to skip the file /
doesn't
> pop up a password prompt.
oh, that's interesting. Can you please file a bugreport and assign it to me
so
we can keep track of this? Thanks!

Cheerio!
-slow

On Mon, Aug 7, 2017 at 1:15 PM, Andrew Walker via samba <
samba at lists.samba.org> wrote:
> >
> > 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 was just curious about whether the behavior is configurable, and now the
> curiosity is satisfied. :-)
>
It's not configurable at the moment and there is a hard limit of 64K set in
the get_ea_value() function:

NTSTATUS get_ea_value(TALLOC_CTX *mem_ctx, connection_struct *conn,
                      files_struct *fsp, const char *fname,
                      const char *ea_name, struct ea_struct *pea)
{
        /* Get the value of this xattr. Max size is 64k. */
        size_t attr_size = 256;
        char *val = NULL;
        ssize_t sizeret;

 again:

        val = talloc_realloc(mem_ctx, val, char, attr_size);
        if (!val) {
                return NT_STATUS_NO_MEMORY;
        }

        if (fsp && fsp->fh->fd != -1) {
                sizeret = SMB_VFS_FGETXATTR(fsp, ea_name, val, attr_size);
        } else {
                sizeret = SMB_VFS_GETXATTR(conn, fname, ea_name, val,
attr_size);
        }

        if (sizeret == -1 && errno == ERANGE && attr_size !=
65536) {
                attr_size = 65536;
                goto again;
        }

        if (sizeret == -1) {
                return map_nt_error_from_unix(errno);
        }

So, the size of the returned buffer could be either 256 byte or 64K :) Nice
selection! I'm not certain, why this choice was made, possibly for the
speed, as at least native implementation of the SMB_VFS_GETXATTR() supports
semantics where if NULL/0 passed as attribute value and size a required
buffer size is returned, which then can be used to allocate memory for it.

Another nastiness of the SET/GET/LIST/RMXATTR API is that you have to
allocate full size buffer in memory to place the XATTR on disk, so if it's
a large chunk of data you can easily run out of memory...

With best regards,
Timur Bakeyev

On Mon, Aug 07, 2017 at 06:15:09AM -0500, Andrew Walker via samba
wrote:
> >
> > 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 :-)
Almost certainly malware. The primary use case for streams is
malware or CIA-exfiltration of your company data (I'm not joking,
the Wikileaks documents have the details).