Created attachment 9364 [details] Possible bug fix When creating a file on a share with streams support via vfs_streams_xattr, files stored by an OSX client do not display their properties and resource fork in finder. Debugging shows that the problem is related to vfs_streams_xattr because vfs_streams_depot works. Steps to show behaviour on windows: Use a share like this: [test] comment = test browseable = yes writable = yes case sensitive = yes path = /data/test nt acl support = no vfs objects = zfsacl streams_xattr store dos attributes = yes ea support = yes Using the windows client, create a file test.txt, then * Storing an alternate stream (echo >test.txt:stream1) works * Retrieving the alternate stream (type test.txt:stream1) works * Listing the alternate streams of test.txt with a tool like stream explorer fails. This is also the reason why the OSX client fails, it seems to list the streams before it tries to access them. Debugging: The problem seems to be the function bsd_attr_list() in lib/replace/xattr.c. It calls extattr_get_file() for both system and user extattr namespace. The first call for the system namespace fails with EPERM if the user is not root, making bsd_attr_list() fail. Attached patch to ignore EPERM on system namespace seems to fix the problem for me.
looks reasonable, but i thought of the following approach also: when iterating through the extattr namespaces in bsd_attr_list(), skip the EXTATTR_NAMESPACE_SYSTEM namespace when we are not running as root. This would also reduce some overhead.
this is fixed with 374b2cfde74e0c61f4b2da724b30d0e430596092 in master, which can (and should) be cherry-picked to 4.0 and 4.1.
Patch in master - looks good to me. Should apply cleanly to 4.1.next, 4.0.next, 3.6.next. Jeremy.
Works for me, thanks!
Pushed to autobuild-v4-1-test and autobuild-v4-0-test. Does not apply to current v3-6-test. Is it very important for 3.6?
for people with *BSD servers and OS X clients it's a nasty bug but it is not a security problem, so 3.6, which is security-fixes-only-mode does not need this.
(In reply to comment #6) > for people with *BSD servers and OS X clients it's a nasty bug but it is not a > security problem, so 3.6, which is security-fixes-only-mode does not need this. There will be one last maintenance release of Samba 3.6. So if it's worth it and someone provides a patch...
Created attachment 9410 [details] git-am fix for 3.6.next Back-port for 3.6.next. Jeremy.
(In reply to comment #8) > Created attachment 9410 [details] > git-am fix for 3.6.next > > Back-port for 3.6.next. > > Jeremy. Thanks a lot, Jeremy! Pushed to v3-6-test.
This fix breaks build in case --enable-uid-wrapper or --enable-nss-wrapper is enabled. The fix is trivial though, see the attachment.
Created attachment 9438 [details] Expose geteuid function call