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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
I haven't figured out how to properly add a crashing test to
"knownfail", so this is added after the fix.
Signed-off-by: Volker Lendecke <vl@samba.org>
When using this with a trigger message in smbd it will crash at
rundown in messaging_deregister because the global messaging context
can be TALLOC_FREE'ed before the background job is freed.
Using messaging_filtered_send already takes care of this situation
properly.
Signed-off-by: Volker Lendecke <vl@samba.org>
Reviewed-by: Jeremy Allison <jra@samba.org>
This function was reported as containing a bug, but it is unused and so
can be safely removed.
BUG: https://bugzilla.samba.org/show_bug.cgi?id=4153
Signed-off-by: Joseph Sutton <josephsutton@catalyst.net.nz>
Reviewed-by: Jeremy Allison <jra@samba.org>
Reviewed-by: David Mulder <dmulder@samba.org>
Autobuild-User(master): Jeremy Allison <jra@samba.org>
Autobuild-Date(master): Thu Apr 1 17:50:49 UTC 2021 on sn-devel-184
This allows to set the 'log level' for clients on the command line:
make test TESTS=wurst CLIENT_LOG_LEVEL=10
Signed-off-by: Andreas Schneider <asn@samba.org>
Reviewed-by: Jeremy Allison <jra@samba.org>
Autobuild-User(master): Jeremy Allison <jra@samba.org>
Autobuild-Date(master): Wed Mar 31 21:20:23 UTC 2021 on sn-devel-184
state->call should not be talloc'ed off a long-lived context
BUG: https://bugzilla.samba.org/show_bug.cgi?id=14675
CI: https://gitlab.com/samba-team/samba/-/merge_requests/1861
Signed-off-by: Volker Lendecke <vl@samba.org>
Reviewed-by: Samuel Cabrero <scabrero@samba.org>
Reviewed-by: Ralph Boehme <slow@samba.org>
Autobuild-User(master): Ralph Böhme <slow@samba.org>
Autobuild-Date(master): Wed Mar 31 12:14:01 UTC 2021 on sn-devel-184
The talloc memory context referenced by the pipe_struct mem_ctx member is used
as talloc parent for RPC response data by the RPC service implementations.
In Samba versions up to 4.10 all talloc children of p->mem_ctx were freed after
a RPC response was delivered by calling talloc_free_children(p->mem_ctx). Commit
60fa8e2552 removed this call which resulted in all
memory allocations on this context not getting released, which can consume
significant memory in long running RPC connections.
Instead of putting the talloc_free_children(p->mem_ctx) back, just use the
mem_ctx argument of the ${pipename}_op_dispatch_internal() function which is a
dcesrv_call_state object created by dcesrv_process_ncacn_packet() and released
by the RPC server when the RPC request processing is finished.
BUG: https://bugzilla.samba.org/show_bug.cgi?id=14675
CI: https://gitlab.com/samba-team/samba/-/merge_requests/1861
Signed-off-by: Ralph Boehme <slow@samba.org>
Reviewed-by: Volker Lendecke <vl@samba.org>
As this is done on existing files, we know that
fsp->base_fsp != NULL and fsp->base_fsp->fh->fd != -1
(i.e. it's a pathref fd) for stream handles.
When getting and setting ACLs on stream handles,
use the fsp->base_fsp instead (as Windows does).
This not only fixes streams_xattr, but will
allow us to later analyze and remove all
special casing code for get/set ACLs on streams
handles.
Remove the knownfail.d/stream-acl file.
Signed-off-by: Jeremy Allison <jra@samba.org>
Reviewed-by: Ralph Boehme <slow@samba.org>
Autobuild-User(master): Jeremy Allison <jra@samba.org>
Autobuild-Date(master): Tue Mar 30 20:14:35 UTC 2021 on sn-devel-184
It shows this isn't done correctly for streams_xattr.
A common config is:
vfs_objects = streams_xattr acl_xattr
to store both streams and Windows ACLs in xattrs.
Unfortunately getting and setting ACLs using handles
opened on stream files isn't being done correctly
in Samba.
This test passes against Windows 10.
This adds tests that prove this doesn't work. Next
patch will add the fix and remove the knownfail.
Signed-off-by: Jeremy Allison <jra@samba.org>
Reviewed-by: Ralph Boehme <slow@samba.org>
smb_strtoull() already checks for negative numbers, but does
it properly, catching " -2" as well as "-2".
Signed-off-by: Douglas Bagnall <douglas.bagnall@catalyst.net.nz>
Reviewed-by: Jeremy Allison <jra@samba.org>
Autobuild-User(master): Jeremy Allison <jra@samba.org>
Autobuild-Date(master): Tue Mar 30 18:55:28 UTC 2021 on sn-devel-184
We don't need it (only 64 bytes) and, well, they annoy people.
Signed-off-by: Douglas Bagnall <douglas.bagnall@catalyst.net.nz>
Reviewed-by: Jeremy Allison <jra@samba.org>
After the first time through the loop, tmp_ctx has been freed and
NULLed, so we end up allocating on NULL and never freeing.
BUG: https://bugzilla.samba.org/show_bug.cgi?id=14659
Signed-off-by: Douglas Bagnall <douglas.bagnall@catalyst.net.nz>
Reviewed-by: Jeremy Allison <jra@samba.org>
If the user doesn't specify a username/password on the command line, we
should use the machine credentials to connect to AD. This is how it is
used by default and we should be able to retrieve SPNs.
Signed-off-by: Andreas Schneider <asn@samba.org>
Reviewed-by: Ralph Boehme <slow@samba.org>
Autobuild-User(master): Ralph Böhme <slow@samba.org>
Autobuild-Date(master): Tue Mar 30 06:48:18 UTC 2021 on sn-devel-184
Following MS-DNSP.
Signed-off-by: Douglas Bagnall <douglas.bagnall@catalyst.net.nz>
Reviewed-by: Jeremy Allison <jra@samba.org>
Autobuild-User(master): Jeremy Allison <jra@samba.org>
Autobuild-Date(master): Tue Mar 30 00:20:53 UTC 2021 on sn-devel-184
MS-DNSP uses the term "EntombedTime" in e.g. "2.2.2.2.4.23 DNS_RPC_RECORD_TS"
which is more descriptive than the generic "timestamp", and less likely to be
confused with dwTimestamp, which has been our curse. Let's make it grep-able,
google-able, and evocative.
Signed-off-by: Douglas Bagnall <douglas.bagnall@catalyst.net.nz>
Reviewed-by: Jeremy Allison <jra@samba.org>
with improved diagnostics on bad arguments
Signed-off-by: Douglas Bagnall <douglas.bagnall@catalyst.net.nz>
Reviewed-by: Jeremy Allison <jra@samba.org>
These give a more detailed message than assertTrue(x in y).
They were new in Python 3.1, so we avoided them until recently.
Signed-off-by: Douglas Bagnall <douglas.bagnall@catalyst.net.nz>
Reviewed-by: Jeremy Allison <jra@samba.org>
We are always setting zone to the same thing which we already know,
and we can reduce cognative stress by mentioning it less and not doing
that weird pop thing.
Signed-off-by: Douglas Bagnall <douglas.bagnall@catalyst.net.nz>
Reviewed-by: Jeremy Allison <jra@samba.org>
We know it "really" just means uint64_t, but we also know it means
100-nanosecond intervals since 1601, and that makes any other use very
confusing (and not just to me, or there wouldn't be these bugs we're
chasing).
In these cases we are talking about 32 bit hours-since-1601 timestamps.
Signed-off-by: Douglas Bagnall <douglas.bagnall@catalyst.net.nz>
Reviewed-by: Jeremy Allison <jra@samba.org>
In places we change NTTIME to uint32_t, because that is what is
actually wanted.
There is one instance of the calculation that we are not changing,
because there are other problems there.
Signed-off-by: Douglas Bagnall <douglas.bagnall@catalyst.net.nz>
Reviewed-by: Jeremy Allison <jra@samba.org>
The dns structs have an unsigned 32 bit timestamp in hours since the
beginning of 1601. In a number of places we need to convert from unix
time to this timestamp, or from the timestamp to NTTIME.
You'll see subsequent patches that make use of these functions.
Signed-off-by: Douglas Bagnall <douglas.bagnall@catalyst.net.nz>
Reviewed-by: Jeremy Allison <jra@samba.org>
Also, since we're there, avoid sorting an array of 1 element.
Signed-off-by: Douglas Bagnall <douglas.bagnall@catalyst.net.nz>
Reviewed-by: Jeremy Allison <jra@samba.org>
Clang gives the following error:
../../libcli/smb/smb2_signing.c:547:48: error:
implicit conversion from enumeration type 'gnutls_mac_algorithm_t'
to different enumeration type 'gnutls_digest_algorithm_t'
[-Werror,-Wenum-conversion]
const size_t digest_len = gnutls_hash_get_len(GNUTLS_MAC_SHA256);
~~~~~~~~~~~~~~~~~~~ ^~~~~~~~~~~~~~~~~
Should be using GNUTLS_DIG_SHA256, which is set to GNUTLS_MAC_SHA256.
Signed-off-by: Gary Lockyer <gary@catalyst.net.nz>
Reviewed-by: Andreas Schneider <asn@samba.org>
Autobuild-User(master): Gary Lockyer <gary@samba.org>
Autobuild-Date(master): Mon Mar 29 23:19:24 UTC 2021 on sn-devel-184
There's no reason to do something special here.
BUG: https://bugzilla.samba.org/show_bug.cgi?id=14449
Signed-off-by: Stefan Metzmacher <metze@samba.org>
Reviewed-by: Jeremy Allison <jra@samba.org>
Autobuild-User(master): Jeremy Allison <jra@samba.org>
Autobuild-Date(master): Mon Mar 29 20:43:28 UTC 2021 on sn-devel-184
The session is valid for the lifetime of the requests anyway
and there's no point in having special handling for compound requests.
BUG: https://bugzilla.samba.org/show_bug.cgi?id=14449
Signed-off-by: Stefan Metzmacher <metze@samba.org>
Reviewed-by: Jeremy Allison <jra@samba.org>
In order to allow replays of requests on a channel failure, we should
not cancel pending requests, the strategie that seems to make windows
clients happy is to let the requests running and return
NT_STATUS_FILE_NOT_AVAILABLE as long as the original request is still
pending.
Here we introduce xconn->transport.shutdown_wait_queue, this is used
to keep the xconn alive for the lifetime of pending requests.
Now we only cancel pending requests if the disconnected connection
is the last channel for a session.
In that case smbXsrv_session_remove_channel() and
smb2srv_session_shutdown_send() will take care of it.
BUG: https://bugzilla.samba.org/show_bug.cgi?id=14449
Signed-off-by: Stefan Metzmacher <metze@samba.org>
Reviewed-by: Jeremy Allison <jra@samba.org>
Otherwise we'll keep the state of already finished requests arround.
This becomes critical as the next commit will cause us to
let pending requests running and keep the xconn alive for
the lifetime of pending requests, so we would not ever
make progress and deadlock.
BUG: https://bugzilla.samba.org/show_bug.cgi?id=14449
Signed-off-by: Stefan Metzmacher <metze@samba.org>
Reviewed-by: Jeremy Allison <jra@samba.org>
Before processing an open we need to reserve the replay cache entry
in order to signal that we're still in progress.
If a reserved record is already present we need to return
FILE_NOT_AVAILABLE in order to let the client retry again.
[MS-SMB2] contains this:
<152> Section 3.2.5.1: For the following error codes, Windows-based clients
will retry the operation up to three times and then retry the operation every 5
seconds until the count of milliseconds specified by Open.ResilientTimeout is
exceeded:
- STATUS_SERVER_UNAVAILABLE
- STATUS_FILE_NOT_AVAILABLE
- STATUS_SHARE_UNAVAILABLE
This works fine for windows clients, but current windows servers seems to
return ACCESS_DENIED instead of FILE_NOT_AVAILABLE.
A Windows server doesn't do any replay detection on pending opens,
which wait for a HANDLE lease to be broken (because of a
SHARING_VIOLATION), at all.
As this is not really documented for the server part of the current [MS-SMB2],
I found the key hint in "SMB 2.2: Bigger. Faster. Scalier - (Parts 1 and 2)"
on page 24. There's a picture showing that a replay gets FILE_NOT_AVAILABLE
as long as the original request is still in progress. See:
https://www.snia.org/educational-library/smb-22-bigger-faster-scalier-parts-1-and-2-2011
A Windows client is unhappy with the current windows server behavior if it
such a situation happens. There's also a very strange interaction with oplock
where the replay gets SHARING_VIOLATION after 35 seconds because it conflicts with
the original open.
I think it's good to follow the intial design from the 2011 presentation and
make the clients happy by using FILE_NOT_AVAILABLE (and differ from Windows).
I'll report that to dochelp@microsoft.com in order to get this hopefully fixed in
their server too).
BUG: https://bugzilla.samba.org/show_bug.cgi?id=14449
Signed-off-by: Stefan Metzmacher <metze@samba.org>
Reviewed-by: Jeremy Allison <jra@samba.org>
There's nothing special regarding the last channel,
as the smb2.session.bind2 test demonstrates.
BUG: https://bugzilla.samba.org/show_bug.cgi?id=14449
Signed-off-by: Stefan Metzmacher <metze@samba.org>
Reviewed-by: Jeremy Allison <jra@samba.org>
This demonstrates that a session and it's open handles is destroyed
when the last explicitly bound channel gets disconnected.
BUG: https://bugzilla.samba.org/show_bug.cgi?id=14449
Signed-off-by: Stefan Metzmacher <metze@samba.org>
Reviewed-by: Jeremy Allison <jra@samba.org>
These demonstrate that the replay detection for pending opens
either doesn't exist (for the share_access=NONE => SHARING_VIOLATION
case) or return the wrong status code => ACCESS_DENIED instead of
FILE_NOT_AVAILABLE.
Windows clients transparently retry after FILE_NOT_AVAILABLE,
while they pass ACCESS_DENIED directly to the application.
I'll report that to dochelp@microsoft.com in order to
clarify the situation.
In the meantime I added tests with a '-windows' suffix,
which demostrate the current windows server behavior,
while the tests with a '-sane' suffix expect the behavior
that whould make windows clients happy.
For Samba I'll implement the '-sane' behavior that
detects all replays and returns FILE_NOT_AVAILABLE
if the original request is still pending.
BUG: https://bugzilla.samba.org/show_bug.cgi?id=14449
Signed-off-by: Stefan Metzmacher <metze@samba.org>
Reviewed-by: Jeremy Allison <jra@samba.org>
We will get this supported later, but for now just disable async
opens as fsp->mid may not belong the first xconn of client->connections.
BUG: https://bugzilla.samba.org/show_bug.cgi?id=14449
Signed-off-by: Stefan Metzmacher <metze@samba.org>
Reviewed-by: Jeremy Allison <jra@samba.org>
