The Samba-Bugzilla – Attachment 17606 Details for
Bug 15186
File creation error with extended attributes with left-over file on Lustre with disabled user_xattr
Home
|
New
|
Browse
|
Search
|
[?]
|
Reports
|
Requests
|
Help
|
New Account
|
Log In
[x]
|
Forgot Password
Login:
[x]
[patch]
git-am fix for 4.17.next.
15186-4.17.patch (text/plain), 5.26 KB, created by
Jeremy Allison
on 2022-10-28 19:36:36 UTC
(
hide
)
Description:
git-am fix for 4.17.next.
Filename:
MIME Type:
Creator:
Jeremy Allison
Created:
2022-10-28 19:36:36 UTC
Size:
5.26 KB
patch
obsolete
>From 6988fa317478435eceb92efae5a7c51123421cb5 Mon Sep 17 00:00:00 2001 >From: Daniel Kobras <kobras@puzzle-itc.de> >Date: Mon, 26 Sep 2022 10:27:19 +0200 >Subject: [PATCH 1/2] s3: smbd: Consistently map EAs to user namespace > >Samba has always been mapping Windows EAs to the 'user' namespace on the >POSIX side. However, in the opposite direction, the mapping would also map >other user-readable POSIX EA namespaces to Windows EAs, only stripping the >'user' namespace prefix, and passing all other EA names verbatim. > >This means any POSIX EA 'other.foo' collides with 'user.other.foo' on the >Windows side, hence the mapping of non-user namespaces is unreliable. >Also, copy operations via Windows would rename an existing POSIX EA >'other.foo' in the source file to 'user.other.foo' in the destination. The >'user' namespace, however, may not be enabled on the underlying filesystem, >leading to subtle failure modes like the ones reported in eg. ><https://bugzilla.samba.org/show_bug.cgi?id=15186> > >Fix the issues by restricting the mapping to the 'user' POSIX EA namespace >consistently for either direction. > >Link: https://lists.samba.org/archive/samba-technical/2022-September/137634.html >BUG: https://bugzilla.samba.org/show_bug.cgi?id=15186 > >Signed-off-by: Daniel Kobras <kobras@puzzle-itc.de> >Reviewed-by: Michael Weiser <michael.weiser@atos.net> >Tested-by: Michael Weiser <michael.weiser@atos.net> >Reviewed-by: Jeremy Allison <jra@samba.org> >Reviewed-by: Volker Lendecke <vl@samba.org> >(cherry picked from commit 34c6db64c2ff62673f8df218487cda4139c10843) >--- > source3/smbd/smb2_trans2.c | 23 +++++++++++++++++++++-- > 1 file changed, 21 insertions(+), 2 deletions(-) > >diff --git a/source3/smbd/smb2_trans2.c b/source3/smbd/smb2_trans2.c >index b2a0cc4140a..8d1e31df1f3 100644 >--- a/source3/smbd/smb2_trans2.c >+++ b/source3/smbd/smb2_trans2.c >@@ -454,7 +454,19 @@ static NTSTATUS get_ea_list_from_fsp(TALLOC_CTX *mem_ctx, > struct ea_list *listp; > fstring dos_ea_name; > >- if (strnequal(names[i], "system.", 7) >+ /* >+ * POSIX EA names are divided into several namespaces by >+ * means of string prefixes. Usually, the system controls >+ * semantics for each namespace, but the 'user' namespace is >+ * available for arbitrary use, which comes closest to >+ * Windows EA semantics. Hence, we map POSIX EAs from the >+ * 'user' namespace to Windows EAs, and just ignore all the >+ * other namespaces. Also, a few specific names in the 'user' >+ * namespace are used by Samba internally. Filter them out as >+ * well, and only present the EAs that are available for >+ * arbitrary use. >+ */ >+ if (!strnequal(names[i], "user.", 5) > || samba_private_attr_name(names[i])) > continue; > >@@ -780,7 +792,14 @@ NTSTATUS set_ea(connection_struct *conn, files_struct *fsp, > int ret; > fstring unix_ea_name; > >- fstrcpy(unix_ea_name, "user."); /* All EA's must start with user. */ >+ /* >+ * Complementing the forward mapping from POSIX EAs to >+ * Windows EAs in get_ea_list_from_fsp(), here we map in the >+ * opposite direction from Windows EAs to the 'user' namespace >+ * of POSIX EAs. Hence, all POSIX EA names the we set here must >+ * start with a 'user.' prefix. >+ */ >+ fstrcpy(unix_ea_name, "user."); > fstrcat(unix_ea_name, ea_list->ea.name); > > canonicalize_ea_name(fsp, unix_ea_name); >-- >2.34.1 > > >From e3c919132d743ce96bcbd0f4415259f638561ade Mon Sep 17 00:00:00 2001 >From: Daniel Kobras <kobras@puzzle-itc.de> >Date: Fri, 21 Oct 2022 16:40:14 +0200 >Subject: [PATCH 2/2] docs-xml: ea support option restricted to user ns > >Update documentation to match current behavior. > >Signed-off-by: Daniel Kobras <kobras@puzzle-itc.de> >Reviewed-by: Jeremy Allison <jra@samba.org> >Reviewed-by: Volker Lendecke <vl@samba.org> > >BUG: https://bugzilla.samba.org/show_bug.cgi?id=15186 > >Autobuild-User(master): Volker Lendecke <vl@samba.org> >Autobuild-Date(master): Fri Oct 28 07:24:18 UTC 2022 on sn-devel-184 > >(cherry picked from commit 69273c3a836ede97c7fde74e2f1fdc84e92ec86f) >--- > docs-xml/smbdotconf/protocol/easupport.xml | 9 +++++++++ > 1 file changed, 9 insertions(+) > >diff --git a/docs-xml/smbdotconf/protocol/easupport.xml b/docs-xml/smbdotconf/protocol/easupport.xml >index 403e48f5a89..0ff9d32f964 100644 >--- a/docs-xml/smbdotconf/protocol/easupport.xml >+++ b/docs-xml/smbdotconf/protocol/easupport.xml >@@ -14,8 +14,17 @@ > attributes (e.g. the getfattr<manvolnum>1</manvolnum> / setfattr<manvolnum>1</manvolnum> > utilities must work). > </para></listitem> >+ <listitem><para>Access to extended user attributes must be allowed by the underlying >+ filesystem (e.g. when mounted with a system-dependent option like user_xattr on Linux). >+ </para></listitem> > </itemizedlist> > <para> >+ This option exposes the "user" attribute namespace from the underlying filesystem to >+ clients. In order to match Windows conventions, the namespace prefix ("user.") is >+ stripped from the attribute name on the client side. The handling of further attribute >+ namespaces (like "security", "system", or "trusted") is not affected by this option. >+ </para> >+ <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 >-- >2.34.1 >
You cannot view the attachment while viewing its details because your browser does not support IFRAMEs.
View the attachment on a separate page
.
View Attachment As Raw
Flags:
vl
:
review+
Actions:
View
Attachments on
bug 15186
:
17531
|
17532
|
17533
| 17606