[PATCH] Fix bug #11589 - turning off EA's can create files incorrectly.

[Uri Simchoni]

Pushed to autobuild. There are small holes in the scheme yet:
- If the attribute is a samba private attribute, then the create fails 
but file gets created
- If ea's are enabled and the underlying file system does not support 
them or otherwise fails to set them (e.g. >4K) - failure and file gets 
created.

To cover both these cases we can take care to delete the file if ea 
setting fails, which may prove to be surprisingly difficult to do 
without a race....

Uri.

On 11/04/2015 07:40 PM, Jeremy Allison wrote:
> On Wed, Nov 04, 2015 at 04:12:47AM +0200, Uri Simchoni wrote:
>> The SMB1 handlers for this (TRANSACT2_OPEN and NT_TRANSACT_CREATE)
>> block it at the protocol level before going to VFS. Which approach
>> do you think is more correct?
> Hmmmm - I hadn't noticed that before... good point.
>
>> It does seem like a detail of the underlying file system (also
>> according to MS-SMB2), but I'm just asking because maybe there were
>> good reasons to place this check at the SMB layer...
> Haha. Would that that were so. Samba grew more organically
> than that over the years :-).
>
> The checks were placed there probably to avoid
> having to unmarshall the EA's if the underlying
> filesystem didn't support it.
>
> However, the reason to keep them is to allow a VFS that supports
> EA's to be overridden if "ea support = no" is set in the
> share definition of the smb.conf.
>
> In that spirit, let me propose this patch instead,
> which does the same thing at the same level as the
> SMB1 checks. The original patch works, but could allow a custom
> VFS to override "ea support = no" in smb.conf,
> which we shouldn't allow to happen I think.
>
> Can you re-review the attached patch ?
>
> Thanks,
>
> Jeremy.