[Samba] FreeBSD samba server returns nt_status_acces_denied when DosStream xattr larger than 64KB

[Timur I. Bakeyev]

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