<feed xmlns='http://www.w3.org/2005/Atom'>
<title>samba.git/source3/script/tests/test_delete_stream.sh, branch master</title>
<subtitle>Unnamed repository; edit this file 'description' to name the repository.</subtitle>
<link rel='alternate' type='text/html' href='https://git.exis.tech/samba.git/'/>
<entry>
<title>CI: add a test trying to delete a stream on a pathref ("stat open") handle</title>
<updated>2022-08-10T15:32:35+00:00</updated>
<author>
<name>Ralph Boehme</name>
<email>slow@samba.org</email>
</author>
<published>2022-07-27T11:37:32+00:00</published>
<link rel='alternate' type='text/html' href='https://git.exis.tech/samba.git/commit/?id=23bc760ec5d61208c2d8778991e3d7e202eab352'/>
<id>23bc760ec5d61208c2d8778991e3d7e202eab352</id>
<content type='text'>
When using vfs_streams_xattr, for a pathref handle of a stream the system fd
will be a fake fd created by pipe() in vfs_fake_fd().

For the following callchain we wrongly pass a stream fsp to
SMB_VFS_FGET_NT_ACL():

SMB_VFS_CREATE_FILE(..., "file:stream", ...)
=&gt; open_file():
   if (open_fd):
   -&gt; taking the else branch:
   -&gt; smbd_check_access_rights_fsp(stream_fsp)
      -&gt; SMB_VFS_FGET_NT_ACL(stream_fsp)

This is obviously wrong and can lead to strange permission errors when using
vfs_acl_xattr:

in vfs_acl_xattr we will try to read the stored ACL by calling
fgetxattr(fake-fd) which of course faild with EBADF. Now unfortunately the
vfs_acl_xattr code ignores the specific error and handles this as if there was
no ACL stored and subsequently runs the code to synthesize a default ACL
according to the setting of "acl:default acl style".

As the correct access check for streams has already been carried out by calling
check_base_file_access() from create_file_unixpath(), the above problem is not
a security issue: it can only lead to "decreased" permissions resulting in
unexpected ACCESS_DENIED errors.

The fix is obviously going to be calling
smbd_check_access_rights_fsp(stream_fsp-&gt;base_fsp).

This test verifies that deleting a file works when the stored NT ACL grants
DELETE_FILE while the basic POSIX permissions (used in the acl_xattr fallback
code) do not.

BUG: https://bugzilla.samba.org/show_bug.cgi?id=15126
MR: https://gitlab.com/samba-team/samba/-/merge_requests/2643

Signed-off-by: Ralph Boehme &lt;slow@samba.org&gt;
Reviewed-by: Volker Lendecke &lt;vl@samba.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
When using vfs_streams_xattr, for a pathref handle of a stream the system fd
will be a fake fd created by pipe() in vfs_fake_fd().

For the following callchain we wrongly pass a stream fsp to
SMB_VFS_FGET_NT_ACL():

SMB_VFS_CREATE_FILE(..., "file:stream", ...)
=&gt; open_file():
   if (open_fd):
   -&gt; taking the else branch:
   -&gt; smbd_check_access_rights_fsp(stream_fsp)
      -&gt; SMB_VFS_FGET_NT_ACL(stream_fsp)

This is obviously wrong and can lead to strange permission errors when using
vfs_acl_xattr:

in vfs_acl_xattr we will try to read the stored ACL by calling
fgetxattr(fake-fd) which of course faild with EBADF. Now unfortunately the
vfs_acl_xattr code ignores the specific error and handles this as if there was
no ACL stored and subsequently runs the code to synthesize a default ACL
according to the setting of "acl:default acl style".

As the correct access check for streams has already been carried out by calling
check_base_file_access() from create_file_unixpath(), the above problem is not
a security issue: it can only lead to "decreased" permissions resulting in
unexpected ACCESS_DENIED errors.

The fix is obviously going to be calling
smbd_check_access_rights_fsp(stream_fsp-&gt;base_fsp).

This test verifies that deleting a file works when the stored NT ACL grants
DELETE_FILE while the basic POSIX permissions (used in the acl_xattr fallback
code) do not.

BUG: https://bugzilla.samba.org/show_bug.cgi?id=15126
MR: https://gitlab.com/samba-team/samba/-/merge_requests/2643

Signed-off-by: Ralph Boehme &lt;slow@samba.org&gt;
Reviewed-by: Volker Lendecke &lt;vl@samba.org&gt;
</pre>
</div>
</content>
</entry>
</feed>
