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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
The whole point of struct GUID_ndr_buf is that this never fails.
Signed-off-by: Volker Lendecke <vl@samba.org>
Reviewed-by: Andrew Bartlett <abartlet@samba.org>
We can announce the ip of the current connection even if it's
a moveable cluster address... as the client is already connected to it.
This change means in a typical ctdb cluster, where we only have public
addresses, the client can at least have more than one multichannel'ed
connection to the public ip.
Signed-off-by: Stefan Metzmacher <metze@samba.org>
Reviewed-by: Günther Deschner <gd@samba.org>
Reviewed-by: Andreas Schneider <asn@samba.org>
To maintain SMB Multichannel, windows client might periodically query with
FSCTL_QUERY_NETWORK_INTERFACE_INFO to get SMB server's network information,
in my case windows server 2022 would do this every 10 minutes (600 seconds).
Consider a scenario: the network information might have changed between
these queries, some become link down, new interface is link up, network
speed is changed, and etc. So far smbd might not aware of these changes and
still report out-of-date network information to windows client, until we
manually send a SIGHUP to smbd in order to trigger load_interfaces():
smbd_sig_hup_handler() > reload_services () > load_interfaces()
This might be a bit inconvenient because it is hard to decide when should
we manually send a SIGHUP to smbd for refreshing network information.
This patch adds load_interfaces() at fsctl_network_iface_info(), while smbd
received FSCTL_QUERY_NETWORK_INTERFACE_INFO would go through this and refresh
local_interfaces, then respond to client with up-to-date network information;
also refresh num_ifaces to make sure interfaces count is consistent.
BUG: https://bugzilla.samba.org/show_bug.cgi?id=15547
Signed-off-by: Jones Syue <jonessyue@qnap.com>
Reviewed-by: Stefan Metzmacher <metze@samba.org>
Reviewed-by: Björn Jacke <bjacke@samba.org>
We missed these values which follow from MS-FSCC 2.3.80 “FSCTL_OFFLOAD_READ
Reply”:
Flags (4 bytes):
A 32-bit unsigned integer that indicates which flags were returned for this
operation. Possible values for the flags follow. All unused bits are reserved
for future use, SHOULD be set to 0, and MUST be ignored.
OFFLOAD_READ_FLAG_ALL_ZERO_BEYOND_CURRENT_RANGE (0x00000001)
=> The data beyond the current range is logically equivalent to zero.
TransferLength (8 bytes):
A 64-bit unsigned integer that contains the amount, in bytes, of data that the
Token logically represents. This value indicates a contiguous region of the
file from the beginning of the requested offset in the FileOffset field in the
FSCTL_OFFLOAD_READ_INPUT data element (section 2.3.79). This value can be
smaller than the CopyLength field specified in the FSCTL_OFFLOAD_READ_INPUT
data element, which indicates that less data was logically
represented (logically read) with the Token than was requested. The value of
this field MUST be greater than 0x0000000000000000 and MUST be aligned to a
logical sector boundary on the volume.
As we currently only implement COPY_CHUNK over the OFFLOAD VFS interface, the
VFS COPY_CHUNK backend in vfs_default just sets both values to 0 and they are
unused in the SMB frontend.
Signed-off-by: Ralph Boehme <slow@samba.org>
Reviewed-by: Jeremy Allison <jra@samba.org>
These calls are used to check whether an IP address is static to the
host, or whether it could be migrated by ctdb.
Combine the calls into a simple ctdbd_public_ip_foreach(cb) function,
which avoids the need to expose struct ctdb_public_ip_list_old.
Signed-off-by: David Disseldorp <ddiss@samba.org>
Reviewed-by: Stefan Metzmacher <metze@samba.org>
Autobuild-User(master): Stefan Metzmacher <metze@samba.org>
Autobuild-Date(master): Wed Oct 14 12:29:56 UTC 2020 on sn-devel-184
The struct fsctl_net_iface_info array needs to be cleaned up.
Signed-off-by: David Disseldorp <ddiss@samba.org>
Reviewed-by: Stefan Metzmacher <metze@samba.org>
Multi-Channel clients should not connect to ctdb public ip addresses
(which move between nodes).
BUG: https://bugzilla.samba.org/show_bug.cgi?id=11898
Signed-off-by: Stefan Metzmacher <metze@samba.org>
Reviewed-by: Günther Deschner <gd@samba.org>
Autobuild-User(master): Stefan Metzmacher <metze@samba.org>
Autobuild-Date(master): Wed Jul 8 17:16:40 UTC 2020 on sn-devel-184
This is not used since commit 74e018f476.
Signed-off-by: Stefan Metzmacher <metze@samba.org>
Reviewed-by: Ralph Boehme <slow@samba.org>
Reviewed-by: Jeremy Allison <jra@samba.org>
...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>
