[PATCHES] de-couple vfs_streams_xattr from "ea support"

[Uri Simchoni]

On 03/03/2017 09:26 AM, Andreas Schneider wrote:
> On Thursday, 2 March 2017 20:37:35 CET Uri Simchoni wrote:
>> "ea support" conf parameter determines whether smbd will handle SMB
>> requests related to extended attributes. vfs_streams_xattr currently
>> requires "ea support = yes", or it won't list streams, but doesn't seem
>> aligned with the desired meaning of "ea support" which is the
>> client-facing behavior, not the storage backend behavior. This is mostly
>> relevant to vfs_fruit and Mac support.
>>
>> This patch set removes this coupling - it allows EA's to be disabled and
>> EA-based streams to be enabled.
>>
>> First two patches are small unrelated cleanups, then the actual change,
>> then changes to documentation, selftest, and testparm.
>>
>> Review appreciated,
>> Uri.
> 
> While you guys are working on this. Could you please update
> 
> docs-xml/smbdotconf/protocol/easupport.xml
> 
> It more or less states that this option is only for OS/2 support ...
> 
> 
> 
> Thanks,
> 
> 
> 	Andreas
> 
> 
How about this edit?

Thanks,
Uri.

-------------- next part --------------
>From 218c9ec34a03cec185af7bced42d1f97a6401d03 Mon Sep 17 00:00:00 2001
From: Uri Simchoni <uri at samba.org>
Date: Fri, 3 Mar 2017 22:00:00 +0200
Subject: [PATCH] doc: update "ea support" section of the smb.conf manpage

This section was badly outdated.

Signed-off-by: Uri Simchoni <uri at samba.org>
---
 docs-xml/smbdotconf/protocol/easupport.xml | 27 +++++++++++++++++++++------
 1 file changed, 21 insertions(+), 6 deletions(-)

diff --git a/docs-xml/smbdotconf/protocol/easupport.xml b/docs-xml/smbdotconf/protocol/easupport.xml
index 4c98267..b453b86 100644
--- a/docs-xml/smbdotconf/protocol/easupport.xml
+++ b/docs-xml/smbdotconf/protocol/easupport.xml
@@ -4,12 +4,27 @@
                  xmlns:samba="http://www.samba.org/samba/DTD/samba-doc">
 <description>
     <para>This boolean parameter controls whether <citerefentry><refentrytitle>smbd</refentrytitle>                                       
-    <manvolnum>8</manvolnum></citerefentry> will allow clients to attempt to store OS/2 style Extended
-    attributes on a share. In order to enable this parameter the underlying filesystem exported by
-    the share must support extended attributes (such as provided on XFS and EXT3 on Linux, with the
-    correct kernel patches). On Linux the filesystem must have been mounted with the mount
-        option user_xattr in order for extended attributes to work, also
-		extended attributes must be compiled into the Linux kernel.</para>
+    <manvolnum>8</manvolnum></citerefentry> will allow clients to attempt to access extended
+    attributes on a share. In order to enable this parameter on a setup with default VFS modules:
+    </para>
+    <itemizedlist>
+	<listitem><para>Samba must have been built with extended attributes support.
+	</para></listitem>
+	<listitem><para>The underlying filesystem exposed by the share must support extended
+	attributes (e.g. the getfattr<manvolnum>1</manvolnum> / setfattr<manvolnum>1</manvolnum>
+	utilities must work).
+	</para></listitem>
+    </itemizedlist>
+    <para>
+    Note that the SMB protocol allows setting attributes whose value is 64K bytes long,
+    and that on NTFS, the maximum storage space for extended attributes per file is 64K.
+    On most UNIX systems (Solaris and ZFS file system being the exception), the limits
+    are much lower - typically 4K. Worse, the same 4K space is often used to store
+    system metadata such as POSIX ACLs, or Samba's NT ACLs. Giving clients
+    access to this tight space via extended attribute support could consume all
+    of it by unsuspecting client applications, which would prevent changing
+    system metadata due to lack of space.
+    </para>
 </description>
 
 <value type="default">no</value>
-- 
2.9.3