IF YOU WOULD LIKE TO GET AN ACCOUNT, please write an
email to Administrator. User accounts are meant only to access repo
and report issues and/or generate pull requests.
This is a purpose-specific Git hosting for
BaseALT
projects. Thank you for your understanding!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
...and instead use the fsctl to infer required behaviour in the VFS
backends.
Note that this removes the check from vfs_default because there we only
handle FSCTL_SRV_COPYCHUNK(_WRITE) and must always perform the lock
checks.
Signed-off-by: Ralph Boehme <slow@samba.org>
Reviewed-by: Stefan Metzmacher <metze@samba.org>
Remove the source fsp argument and instead pass the offload token
generated with SMB_VFS_OFFLOAD_READ_SEND/RECV.
An actual offload fsctl is not implemented yet, neither in the VFS nor
at the SMB ioctl layer, and returns NT_STATUS_NOT_IMPLEMENTED
With these changes we now pass the copy-chunk-across-shares test.
Signed-off-by: Ralph Boehme <slow@samba.org>
Reviewed-by: Stefan Metzmacher <metze@samba.org>
The copy-chunk request chunk_count can be 0 and Windows server just
returns success saying number of copied chunks is 0.
macOS client overload this after negotiating AAPL via their SMB2
extensions, meaning it's a so called copyfile request (copy whole file
and all streams).
We previously checked this at the SMB layer, with this patch we just
send this down the VFS, if vfs_fruit is loaded it implements the macOS
copyile semantics, otherwise we get Windows behavour..
No change in behaviour.
Signed-off-by: Ralph Boehme <slow@samba.org>
Reviewed-by: Stefan Metzmacher <metze@samba.org>
As we won't have the source fsp around with the coming token based
offload read/write based code, we can't merge chunks as that requires
checking against the source file size.
We could still merge chunks without checking, but getting the error
handling correct would require comlicated logic for the SMB2 ioctl
copy-chunk error reporting.
Signed-off-by: Ralph Boehme <slow@samba.org>
Reviewed-by: Stefan Metzmacher <metze@samba.org>
By adding a SMB2 specific CHECK_READ_SMB2 macro called that always
grants read access if execute was granted, we can get rid of the flags2
hack.
All callers in the SMB2 code are converted to use the CHECK_READ_SMB2
macro.
Amongs other things, this later allows moving the handle checks in
copychunk_check_handles() down into the VFS layer where we don't have
access to the smbreq.
Signed-off-by: Ralph Boehme <slow@samba.org>
Reviewed-by: Stefan Metzmacher <metze@samba.org>
No change in behaviour, just a rename in preperation of more changes to
SMB_VFS_OFFLOAD_WRITE_SEND. It helps keeping the diff of the actual
changes smaller.
Signed-off-by: Ralph Boehme <slow@samba.org>
Reviewed-by: Stefan Metzmacher <metze@samba.org>
No change in behaviour, this just uses the new SMB_VFS_OFFLOAD_READ_SEND
in the duplicate extents and the resume key ioctls.
In the copy-chunk/resume-key case this means using
SMB_VFS_OFFLOAD_READ_SEND to create the resume-key token that is
returned to the client.
In the duplicate-extents case this ensures we can later call
offload-write, which requires a previous call to offload-read that
associates a token with a file-handle.
Signed-off-by: Ralph Boehme <slow@samba.org>
Reviewed-by: Stefan Metzmacher <metze@samba.org>
A client that supports SMB3 will do a signed FSCTL_VALIDATE_NEGOTIATE_INFO
after a tree connect. This FSCTL_VALIDATE_NEGOTIATE_INFO call contains
the client capabilities, client guid, security mode and the array of supported
dialects. But if SMB 2.02 is negotiated the doesn't send these values to the
server in the first connection attempt (when the client starts with a SMB1 Negotiate).
Windows servers that only support SMB2 just return NT_STATUS_FILE_CLOSED
as answer to FSCTL_VALIDATE_NEGOTIATE_INFO.
We should do the same if we just pretend to support SMB 2.02,
as SMB 2.10 always include an SMB2 Negotiate request we can leave it as is.
BUG: https://bugzilla.samba.org/show_bug.cgi?id=12772
Signed-off-by: Stefan Metzmacher <metze@samba.org>
Reviewed-by: Andreas Schneider <asn@samba.org>
FSCTL_DUPLICATE_EXTENTS_TO_FILE must be handled as a COW clone. Add a
copy-chunk flags parameter to the VFS to handle this.
Signed-off-by: Aurelien Aptel <aaptel@suse.com>
Signed-off-by: David Disseldorp <ddiss@samba.org>
Reviewed-by: Ralph Böhme <slow@samba.org>
Merge chunks with adjacent ranges. This results in fewer IO requests for
the typical server-side file copy usecase: just one 16 MB copy instead
of sixteen 1 MB.
Signed-off-by: Ralph Boehme <slow@samba.org>
Reviewed-by: Jeremy Allison <jra@samba.org>
Later commits will make the low level copy-chunk implementation async
using a thread pool. That means the individual chunks may be scheduled
and copied out-of-order at the low level.
According to conversation with MS Dochelp, a server implementation
must process individual chunks in order.
Signed-off-by: Ralph Boehme <slow@samba.org>
Reviewed-by: Jeremy Allison <jra@samba.org>
No change, in behaviour, just preperational stuff to unroll the core
copy loop.
Signed-off-by: Ralph Boehme <slow@samba.org>
Reviewed-by: Jeremy Allison <jra@samba.org>
This commits sets the stage for a change of behavior
in a later commit.
When checking FILE_READ_DATA on the COPYCHUNK dest handle,
only check the handle readability and not the extra right
that may have been added due to the FILE_EXECUTE right.
The check for FILE_READ_DATA always seemed strange for the
dest handle, which is not read. It turns out that in Windows,
this check is not done at the SMB layer, but at a lower layer
that processes the IOCTL request - the IOCTL code has bits
that specify what type of access check needs to be done.
Therefore, this lower layer is unaware of the SMB layer's
practice of granting READ access based on the FILE_EXECUTE
right, and it only checks the handle's readability.
This subtle difference has observable behavior - the
COPYCHUNK source handle can have FILE_EXECUTE right instead
of FILE_READ_DATA, but the dest handle cannot.
BUG: https://bugzilla.samba.org/show_bug.cgi?id=12149
Signed-off-by: Uri Simchoni <uri@samba.org>
Reviewed-by: David Disseldorp <ddiss@samba.org>
Autobuild-User(master): David Disseldorp <ddiss@samba.org>
Autobuild-Date(master): Tue Aug 16 15:21:03 CEST 2016 on sn-devel-144
This effectively disables it for now.
Ultimately, we may want to remove this restriction.
Hence a separate patch.
Signed-off-by: Michael Adam <obnox@samba.org>
Reviewed-by: Stefan Metzmacher <metze@samba.org>
Autobuild-User(master): Michael Adam <obnox@samba.org>
Autobuild-Date(master): Tue Jan 26 10:40:44 CET 2016 on sn-devel-144
The ioctl used for detecting interfaces for multi-channel.
Pair-Programmed-With: Michael Adam <obnox@samba.org>
Signed-off-by: Stefan Metzmacher <metze@samba.org>
Signed-off-by: Michael Adam <obnox@samba.org>
Apple's special copy_chunk ioctl that requests a copy of the whole file
along with all attached metadata.
These copy_chunk requests have a chunk count of 0 that we translate to a
copy_chunk_send VFS call overloading the parameters src_off = dest_off =
num = 0.
Bug: https://bugzilla.samba.org/show_bug.cgi?id=11317
Signed-off-by: Ralph Boehme <slow@samba.org>
Reviewed-by: Stefan Metzmacher <metze@samba.org>
tevent_req_nterror must be called directly as the last step before
returning with tevent_req_post.
Signed-off-by: Ralph Boehme <slow@samba.org>
Reviewed-by: Stefan Metzmacher <metze@samba.org>
We need to use the connection that is used by the current request.
Signed-off-by: Stefan Metzmacher <metze@samba.org>
Reviewed-by: Volker Lendecke <vl@samba.org>
Reviewed-by: Michael Adam <obnox@samba.org>
It turns out that all the client and server need to agree on is what
protocol should have been negotiated. If they disagree, they should
disconnect. The contents of the list of protocols used during
negotiate and during FSCTL_VALIDATE_NEGOTIATE_INFO do not need to match.
Signed-off-by: Ira Cooper <ira@samba.org>
Reviewed-by: Stefan Metzmacher <metze@samba.org>
Autobuild-User(master): Stefan Metzmacher <metze@samba.org>
Autobuild-Date(master): Mon Jun 23 14:28:25 CEST 2014 on sn-devel-104
SIVAL writes 32 bit, not 16
Signed-off-by: Volker Lendecke <vl@samba.org>
Reviewed-by: Michael Adam <obnox@samba.org>
Autobuild-User(master): Michael Adam <obnox@samba.org>
Autobuild-Date(master): Fri Feb 7 20:07:23 CET 2014 on sn-devel-104
As documented in MS-SMB2 3.3.5.15.6 Handling a Server-Side Data Copy
Request, an invalid parameter response should be sent when:
The Length value in a single chunk is greater than
ServerSideCopyMaxChunkSize or *equal to zero*.
We do not currently abide by the latter part of this clause.
BUG: https://bugzilla.samba.org/show_bug.cgi?id=10424
Signed-off-by: David Disseldorp <ddiss@samba.org>
Reviewed-by: Jeremy Allison <jra@samba.org>
FSCTL_SRV_COPYCHUNK can only be used when the client has the copy-chunk
target file open with FILE_WRITE_DATA and FILE_READ_DATA.
FSCTL_SRV_COPYCHUNK_WRITE requires only FILE_WRITE_DATA access on the
target, and is therefore suitable for cp --reflink, which opens the
target file O_WRONLY.
Signed-off-by: David Disseldorp <ddiss@samba.org>
Reviewed-by: Jeremy Allison <jra@samba.org>
This can cause compile errors on 32-bit systems.
Signed-off-by: Jeremy Allison <jra@samba.org>
Reviewed-by: Stefan Metzmacher <metze@samba.org>
Autobuild-User(master): Stefan Metzmacher <metze@samba.org>
Autobuild-Date(master): Sat Jan 19 12:14:13 CET 2013 on sn-devel-104
Previous commit handles this around each read/write call.
Signed-off-by: Jeremy Allison <jra@samba.org>
Reviewed-by: David Disseldorp <ddiss@samba.org>
Autobuild-User(master): David Disseldorp <ddiss@samba.org>
Autobuild-Date(master): Fri Jan 18 01:47:01 CET 2013 on sn-devel-104
Planning to add extra checks to ensure we don't attempt
copychunk on printer or IPC$ handles.
Signed-off-by: Jeremy Allison <jra@samba.org>
Reviewed-by: David Disseldorp <ddiss@samba.org>
Check that the copychunk ioctl request maximum output specified by the
client is large enough to hold copychunk response data.
Reviewed by: Jeremy Allison <jra@samba.org>
Autobuild-User(master): Jeremy Allison <jra@samba.org>
Autobuild-Date(master): Thu Jan 17 00:59:44 CET 2013 on sn-devel-104
[MS-SMB2] 3.3.5.15.6 Handling a Server-Side Data Copy Request, specifies
that the copychunk destination file handle be granted FILE_WRITE_DATA
and FILE_READ_DATA access.
FILE_READ_DATA access must also be granted on the copychunk source file,
which may be done implicitly with execute permission.
Reviewed by: Jeremy Allison <jra@samba.org>
For each chunk in a copychunk request, take a read and write lock on
the source and destination files respectively.
Also change the resume key format to use a combination of the persistent
and volatile handles. Thanks to Metze for his help on this.
Reviewed by: Jeremy Allison <jra@samba.org>
SMB2 clients can issue FSCTL_SRV_COPYCHUNK requests in order to copy
data between files on the server side only, rather than reading data
then writing back from the client. FSCTL_SRV_COPYCHUNK is used by
default for Explorer SMB2 file copies on Windows Server 2012.
2.2.32.1 SRV_COPYCHUNK_RESPONSE in [MS-SMB2] describes the requirement
for the server to provide maximum copychunk request size limits in ioctl
responses carrying STATUS_INVALID_PARAMETER.
Reviewed by: Jeremy Allison <jra@samba.org>
Use existing ioctl IDL infrastructure for marshalling. Support for this
ioctl is a prerequisite for FSCTL_SRV_COPYCHUNK handling.
The client-opaque resume key is constructed using the server side
dev/inode file identifier.
Reviewed by: Jeremy Allison <jra@samba.org>
Add per device type ioctl handler source files for FSCTL_DFS,
FSCTL_FILESYSTEM, FSCTL_NAMED_PIPE and FSCTL_NETWORK_FILESYSTEM.
Reviewed by: Jeremy Allison <jra@samba.org>
