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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
Commit 83fe7a0316d3e5867a56cfdc51ec17f36ea03889 converted the
stdout/stderr logging types to DEBUG_FILE to get a header when using
DEBUG_SYSLOG_FORMAT_ALWAYS. However, this causes all configured
backends to be invoked. When syslog is one of those backends then
this is almost certainly not what is intended.
Instead, call debug_file_log() directly in that special case and
revert the parts of the above commit that convert to file logging.
Most of the changes to debughdrclass() still seem necessary, since
they handle the change of debug_syslog_format from a bool to an enum.
BUG: https://bugzilla.samba.org/show_bug.cgi?id=15460
Signed-off-by: Martin Schwenke <mschwenke@ddn.com>
Reviewed-by: Douglas Bagnall <douglas.bagnall@catalyst.net.nz>
Autobuild-User(master): Martin Schwenke <martins@samba.org>
Autobuild-Date(master): Mon Aug 28 01:21:07 UTC 2023 on atb-devel-224
(cherry picked from commit c7672779128ff12eb7a5cb34052559e62adbd5cb)
Autobuild-User(v4-19-test): Jule Anger <janger@samba.org>
Autobuild-Date(v4-19-test): Mon Aug 28 09:36:36 UTC 2023 on atb-devel-224
BUG: https://bugzilla.samba.org/show_bug.cgi?id=15458
Signed-off-by: Joseph Sutton <josephsutton@catalyst.net.nz>
Reviewed-by: Andrew Bartlett <abartlet@samba.org>
(cherry picked from commit 776597bce922d291257e34f1e3304227265a1dbc)
This landed in master as 34760dfc89e879a889d64b48c606ccbaf10e8ba3.
(This text based strongly on e25d6c89bef298ac8cd8c2fb7b49f6cbd4e05ba5
and b3e043276017c6323afa681df9154df9a4292bd1 in Samba 4.17's WHATSNEW)
BUG: https://bugzilla.samba.org/show_bug.cgi?id=15457
Signed-off-by: Andrew Bartlett <abartlet@samba.org>
Autobuild-User(v4-19-test): Jule Anger <janger@samba.org>
Autobuild-Date(v4-19-test): Fri Aug 25 09:02:28 UTC 2023 on atb-devel-224
We send the NC root first, as a special case for every chunk
that we send until the natural point where it belongs.
We do not bump the tmp_highest_usn in the highwatermark that
the client and server use (it is meant to be an opauqe cookie)
until the 'natural' point where the object appears, similar
to the cache for GET_ANC.
The issue is that without this, because the NC root was sorted
first in whatever chunk it appeared in but could have a 'high'
highwatermark, Azure AD Connect will send back the same
new_highwatermark->tmp_highest_usn, and due to a bug,
a zero reserved_usn, which makes Samba discard it.
The reserved_usn is now much less likely to ever be set because
the tmp_higest_usn is now always advancing.
RN: Avoid infinite loop in initial user sync with Azure AD Connect
when synchronising a large Samba AD domain.
BUG: https://bugzilla.samba.org/show_bug.cgi?id=15401
Signed-off-by: Andrew Bartlett <abartlet@samba.org>
Reviewed-by: Stefan Metzmacher <metze@samba.org>
(cherry picked from commit 79ca6ef28a6f94965cb030c4a7da8c1b9db7150b)
Autobuild-User(v4-19-test): Jule Anger <janger@samba.org>
Autobuild-Date(v4-19-test): Fri Aug 18 10:33:44 UTC 2023 on atb-devel-224
This is closer to our READDME.Coding style
BUG: https://bugzilla.samba.org/show_bug.cgi?id=15401
Signed-off-by: Andrew Bartlett <abartlet@samba.org>
Reviewed-by: Stefan Metzmacher <metze@samba.org>
(cherry picked from commit 2aba9e230ea62efcbd829f6f073894dfa3180c91)
Because of the requirement to echo back the original string, we can
not force this to be a trustworthy value.
BUG: https://bugzilla.samba.org/show_bug.cgi?id=15401
Signed-off-by: Andrew Bartlett <abartlet@samba.org>
Reviewed-by: Stefan Metzmacher <metze@samba.org>
(cherry picked from commit 2ed9815eeacfcf3a58871bafe0212398cc34c39e)
This tries to avoid it appearing that ncRoot is a value that can
be trusted and used internally by not updating it and instead leaving
it just as an input/echo-back value.
BUG: https://bugzilla.samba.org/show_bug.cgi?id=15401
Signed-off-by: Andrew Bartlett <abartlet@samba.org>
Reviewed-by: Stefan Metzmacher <metze@samba.org>
(cherry picked from commit 548f141f11e89d335d8f9d74ab6925fa6b90fb84)
This avoids the indentation correction being in the previous patch.
BUG: https://bugzilla.samba.org/show_bug.cgi?id=15401
Signed-off-by: Andrew Bartlett <abartlet@samba.org>
Reviewed-by: Stefan Metzmacher <metze@samba.org>
(cherry picked from commit fe7418e1765b79f60945b787536b4d84a548fe02)
This changes the GetNCChanges server to use a per-call state for
extended operations like RID_ALLOC or REPL_OBJ and only maintain
and (more importantly) invalidate the state during normal replication.
This allows REPL_OBJ to be called during a normal replication cycle
that continues using after that call, continuing with the same
highwatermark cookie.
Azure AD will do a sequence of (roughly)
* Normal replication (objects 1..100)
* REPL_OBJ (of 1 object)
* Normal replication (objects 101..200)
However, if there are more than 100 (in this example) objects in the
domain, and the second replication is required, the objects 1..100
are sent, as the replication state was invalidated by the REPL_OBJ call.
RN: Improve GetNChanges to address some (but not all "Azure AD Connect")
syncronisation tool looping during the initial user sync phase.
BUG: https://bugzilla.samba.org/show_bug.cgi?id=15401
Signed-off-by: Andrew Bartlett <abartlet@samba.org>
Reviewed-by: Stefan Metzmacher <metze@samba.org>
(cherry picked from commit 99579e706312192f46df33d55949db7f1475d0d0)
The NC root, on any replication when it appears, is the first object to be
replicated, including for all subsequent chunks in the replication.
However the tmp_highest_usn is not updated by that USN, it must
only be updated for the non-NC changes (to match Windows exactly),
or at least only updated with the non-NC changes until it would
naturally appear.
BUG: https://bugzilla.samba.org/show_bug.cgi?id=15401
Signed-off-by: Andrew Bartlett <abartlet@samba.org>
Reviewed-by: Stefan Metzmacher <metze@samba.org>
(cherry picked from commit 87414955212143b8502b4c02aca150bc72cb8de5)
This demonstrates the behaviour used by the "Azure AD Connect" cloud sync tool.
BUG: https://bugzilla.samba.org/show_bug.cgi?id=15401
Signed-off-by: Andrew Bartlett <abartlet@samba.org>
Reviewed-by: Stefan Metzmacher <metze@samba.org>
(cherry picked from commit b323169d6ff8357f7c999ae346137166c98218ac)
Azure AD Connect will send a GUID but no DummyDN.
BUG: https://bugzilla.samba.org/show_bug.cgi?id=15401
Signed-off-by: Andrew Bartlett <abartlet@samba.org>
Reviewed-by: Stefan Metzmacher <metze@samba.org>
(cherry picked from commit db16366b0bbefcdb91a0b36c903ed63456a081b8)
BUG: https://bugzilla.samba.org/show_bug.cgi?id=15401
Signed-off-by: Andrew Bartlett <abartlet@samba.org>
Reviewed-by: Stefan Metzmacher <metze@samba.org>
(cherry picked from commit 40f831e67e1f312b1db52c74c119899245d03e32)
It is always better to keep the testing OUs unique if possible.
BUG: https://bugzilla.samba.org/show_bug.cgi?id=15401
Signed-off-by: Andrew Bartlett <abartlet@samba.org>
Reviewed-by: Stefan Metzmacher <metze@samba.org>
(cherry picked from commit 628eab11b3c2e82875bf602e363b781d3e5eb96d)
This object is used to hold one of many possible connections and
it is helpful for debugging and uniqueness to know which DC is being
connected to.
BUG: https://bugzilla.samba.org/show_bug.cgi?id=15401
Signed-off-by: Andrew Bartlett <abartlet@samba.org>
Reviewed-by: Stefan Metzmacher <metze@samba.org>
(cherry picked from commit c30bb8769ff2c4eba2d8f8a2bd3a56946b7d9d5e)
This check was valuable before aee2039e63ceeb5e69a0461fb77e0f18278e4dc4
but now only checks things we know to be true, as the value has come
from Samba via drs_ObjectIdentifier_to_dn_and_nc_root() either on this
or a previous call.
BUG: https://bugzilla.samba.org/show_bug.cgi?id=15401
Signed-off-by: Andrew Bartlett <abartlet@samba.org>
Reviewed-by: Stefan Metzmacher <metze@samba.org>
(cherry picked from commit 0550e469eda4022659718ae9a56f5deaa9f9a307)
At this layer we can make a reasonable assumption about being able
to read ldb_errstring() to print that for extra useful debugging.
BUG: https://bugzilla.samba.org/show_bug.cgi?id=15401
Signed-off-by: Andrew Bartlett <abartlet@samba.org>
Reviewed-by: Stefan Metzmacher <metze@samba.org>
(cherry picked from commit 63843a22c8db73d459bee61e73bb1f0d31e3d427)
BUG: https://bugzilla.samba.org/show_bug.cgi?id=15401
Signed-off-by: Andrew Bartlett <abartlet@samba.org>
Reviewed-by: Stefan Metzmacher <metze@samba.org>
(cherry picked from commit a12bcce89d26ae05bbaeed560cf8fcc7b5bcfdab)
This is still unreachable, so but improve the logging
to give more detail in this area anyway.
BUG: https://bugzilla.samba.org/show_bug.cgi?id=15401
Signed-off-by: Andrew Bartlett <abartlet@samba.org>
Reviewed-by: Stefan Metzmacher <metze@samba.org>
(cherry picked from commit d0c1ce53add2fd3b3a4186581f4e214029cbcf1a)
BUG: https://bugzilla.samba.org/show_bug.cgi?id=15401
Signed-off-by: Andrew Bartlett <abartlet@samba.org>
Reviewed-by: Stefan Metzmacher <metze@samba.org>
(cherry picked from commit 0d9ea6c559317e19642662220c089e2d59ef3ecd)
Remove the now unneeded req->xxx = NULL assignments (and the
deliberately bogus req->session = (void *)0xDEADBEEF one
used to demonstrate the bug).
Remove knownfail.
BUG: https://bugzilla.samba.org/show_bug.cgi?id=15432
Signed-off-by: Jeremy Allison <jra@samba.org>
Reviewed-by: Noel Power <npower@samba.org>
Autobuild-User(master): Noel Power <npower@samba.org>
Autobuild-Date(master): Tue Aug 15 12:06:36 UTC 2023 on atb-devel-224
(cherry picked from commit 4145bfb1b5a3639caf26a310d612aec29fc00117)
Autobuild-User(v4-19-test): Jule Anger <janger@samba.org>
Autobuild-Date(v4-19-test): Thu Aug 17 10:31:56 UTC 2023 on atb-devel-224
Found by Robert Morris <rtm@lcs.mit.edu>.
Adds knownfail.
BUG: https://bugzilla.samba.org/show_bug.cgi?id=15432
Signed-off-by: Jeremy Allison <jra@samba.org>
Reviewed-by: Noel Power <nopower@samba.org>
(cherry picked from commit c32df3bb31ce6275cfb91107e34e2d6b3c2fba1b)
If a client does a SMB1 NEGPROT followed by SMB1 TCON
then req->session is left uninitialized.
Show this causes a crash by deliberately initializing
req->session to an invalid pointer. This will be removed
once the test shows the crash, and the fix is added to
cause init_smb1_request() to zero the memory passed in.
BUG: https://bugzilla.samba.org/show_bug.cgi?id=15432
Signed-off-by: Jeremy Allison <jra@samba.org>
Reviewed-by: Noel Power <npower@samba.org>
(cherry picked from commit f02f74e931f5821c7b7c1be2b8f0fb60c9a69b19)
Now that the INT64 claim IDL definition has been corrected, these tests
should pass against Windows.
BUG: https://bugzilla.samba.org/show_bug.cgi?id=15452
Signed-off-by: Joseph Sutton <josephsutton@catalyst.net.nz>
Reviewed-by: Andrew Bartlett <abartlet@samba.org>
Autobuild-User(master): Andrew Bartlett <abartlet@samba.org>
Autobuild-Date(master): Tue Aug 15 19:41:50 UTC 2023 on atb-devel-224
(cherry picked from commit 37fdd79cc0b83b44cb4d4c457fbb8e7410655b24)
This field is supposed to be aligned to eight bytes, but the ‘dlong’
type is aligned to only four bytes. This discrepancy resulted in claims
being encoded and decoded incorrectly.
BUG: https://bugzilla.samba.org/show_bug.cgi?id=15452
Signed-off-by: Joseph Sutton <josephsutton@catalyst.net.nz>
Reviewed-by: Andrew Bartlett <abartlet@samba.org>
(cherry picked from commit aa1815519ce1412cdf25927b54b5178113cdd2a7)
This type behaves like a signed variant of ‘hyper’. Unlike the existing
‘dlong’ type, which has four byte alignment, ‘int64’ is aligned to eight
bytes.
Bump the NDR version to 3.0.1.
BUG: https://bugzilla.samba.org/show_bug.cgi?id=15452
Signed-off-by: Joseph Sutton <josephsutton@catalyst.net.nz>
Reviewed-by: Andrew Bartlett <abartlet@samba.org>
(cherry picked from commit 402bb17693472a9c30f33a0bdf5f5f78df4066cc)
BUG: https://bugzilla.samba.org/show_bug.cgi?id=15452
Signed-off-by: Joseph Sutton <josephsutton@catalyst.net.nz>
Reviewed-by: Andrew Bartlett <abartlet@samba.org>
(cherry picked from commit 0cce616843395215305428b8672ffa315dbdd858)
BUG: https://bugzilla.samba.org/show_bug.cgi?id=15452
Signed-off-by: Joseph Sutton <josephsutton@catalyst.net.nz>
Reviewed-by: Andrew Bartlett <abartlet@samba.org>
(cherry picked from commit 2c915e743d53d5e35fa31fa3965d9c9b086351ec)
Remove knownfail.
BUG: https://bugzilla.samba.org/show_bug.cgi?id=15430
Signed-off-by: Jeremy Allison <jra@samba.org>
Reviewed-by: Noel Power <npower@samba.org>
Autobuild-User(master): Noel Power <npower@samba.org>
Autobuild-Date(master): Mon Aug 14 19:52:49 UTC 2023 on atb-devel-224
(cherry picked from commit d79d0508a4b8bdc4582a350d109181ecae0bf1e2)
Autobuild-User(v4-19-test): Jule Anger <janger@samba.org>
Autobuild-Date(v4-19-test): Tue Aug 15 15:20:43 UTC 2023 on atb-devel-224
Robert Morris <rtm@lcs.mit.edu> noticed a missing
return in reply_exit_done().
Adds knownfail.
BUG: https://bugzilla.samba.org/show_bug.cgi?id=15430
Signed-off-by: Jeremy Allison <jra@samba.org>
Reviewed-by: Noel Power <npower@samba.org>
(cherry picked from commit 63895e03c4e8ed79a3b2cda928f58ec278cd6608)
Now we've fixed srvstr_pull_req_talloc() this isn't
strictly needed, but ensuring pointers are initialized
is best practice to avoid future bugs.
BUG: https://bugzilla.samba.org/show_bug.cgi?id=15420
Signed-off-by: Jeremy Allison <jra@samba.org>
Reviewed-by: Volker Lendecke <vl@samba.org>
Autobuild-User(master): Volker Lendecke <vl@samba.org>
Autobuild-Date(master): Mon Aug 14 15:55:43 UTC 2023 on atb-devel-224
(cherry picked from commit 5379b8d557a9a16b81eafb87b60b81debc4bfccb)
Rather than restore to uninitialized, set to NULL as per
modern coding practices.
BUG: https://bugzilla.samba.org/show_bug.cgi?id=15420
Reviewed-by: Volker Lendecke <vl@samba.org>
Signed-off-by: Jeremy Allison <jra@samba.org>
Reviewed-by: Volker Lendecke <vl@samba.org>
(cherry picked from commit 5bc50d2ea4444244721e72b4264311c7005d2f3c)
Robert Morris <rtm@lcs.mit.edu> noticed that in the case
where srvstr_pull_req_talloc() is being called with
buffer remaining == 0, we don't NULL out the destination
pointed which is *always* done in the codepaths inside
pull_string_talloc(). This prevents a crash in the caller.
Remove knownfail.
BUG: https://bugzilla.samba.org/show_bug.cgi?id=15420
Signed-off-by: Jeremy Allison <jra@samba.org>
Reviewed-by: Volker Lendecke <vl@samba.org>
(cherry picked from commit 9220c45cc191b34e293190f6a923ba463edd5db9)
Shows that we indirect through an uninitialized pointer and the client crashes
it's own smbd.
Add knownfail.
BUG: https://bugzilla.samba.org/show_bug.cgi?id=15420
Signed-off-by: Jeremy Allison <jra@samba.org>
Reviewed-by: Volker Lendecke <vl@samba.org>
(cherry picked from commit 963fd8aa9b76361ab9aeb63307773f2498b17879)
We will need this to show smbd crashing in the test code.
This will be removed once we're passing the test.
BUG: https://bugzilla.samba.org/show_bug.cgi?id=15420
Signed-off-by: Jeremy Allison <jra@samba.org>
Reviewed-by: Volker Lendecke <vl@samba.org>
(cherry picked from commit e7bf94b4e3a7f994aa6f0b859089c5add2ad380f)
Environment setup:
When macOS Finder connect to a samba server with 'spotlight = yes',
macOS would issue mdssvc open (mdssvc.opnum == 0) to samba and it goes
through api _mdssvc_open().
After applied 578e434a94147dc2d7dbfc006d2ab84807859c1d,
(this is reported by jaywei@qnap.com)
this line 'talloc_free(path);' is deleted if _mdssvc_open() normal exit,
so memory is lazy de-allocate: delayed to
smbd_tevent_trace_callback() @ smb2_process.c. [1]
Supposed to explicitly free 'path' in _mdssvc_open() @ srv_mdssvc_nt.c[2]
just like abnormal exit, do not wait for main loop to free 'path' which is
no longer used, this is more consistent while reading source code.
BUG: https://bugzilla.samba.org/show_bug.cgi?id=15449
[1] gdb tracing 'path' address 0x56204ccc67e0 to know how it is freed.
Breakpoint 2, _tc_free_children_internal (tc=0x56204ccc6780, ptr=0x56204ccc67e0, location=0x7ff430d96410 "../../lib/talloc/talloc.c:1714") at ../../lib/talloc/talloc.c:1656
1656 while (tc->child) {
(gdb) bt
0 _tc_free_children_internal (tc=0x56204ccc6780, ptr=0x56204ccc67e0, location=0x7ff430d96410 "../../lib/talloc/talloc.c:1714") at ../../lib/talloc/talloc.c:1656
1 0x00007ff430d92b14 in _tc_free_internal (tc=0x56204ccc6780, location=0x7ff430d96410 "../../lib/talloc/talloc.c:1714") at ../../lib/talloc/talloc.c:1183
2 0x00007ff430d93b71 in _tc_free_children_internal (tc=0x56204ccc6720, ptr=0x56204ccc6780, location=0x7ff430d96410 "../../lib/talloc/talloc.c:1714") at ../../lib/talloc/talloc.c:1668
3 0x00007ff430d93d66 in talloc_free_children (ptr=0x56204ccc6780) at ../../lib/talloc/talloc.c:1714
4 0x00007ff432235aca in talloc_pop (frame=0x56204ccc6780) at ../../lib/util/talloc_stack.c:125
5 0x00007ff430d92959 in _tc_free_internal (tc=0x56204ccc6720, location=0x7ff431f358d0 "../../source3/smbd/process.c:3726") at ../../lib/talloc/talloc.c:1157
6 0x00007ff430d92cd5 in _talloc_free_internal (ptr=0x56204ccc6780, location=0x7ff431f358d0 "../../source3/smbd/process.c:3726") at ../../lib/talloc/talloc.c:1247
7 0x00007ff430d93f96 in _talloc_free (ptr=0x56204ccc6780, location=0x7ff431f358d0 "../../source3/smbd/process.c:3726") at ../../lib/talloc/talloc.c:1791
8 0x00007ff431d81292 in smbd_tevent_trace_callback (point=TEVENT_TRACE_AFTER_LOOP_ONCE, private_data=0x7ffe46591e30) at ../../source3/smbd/process.c:3726
<...cut...>
[2] gdb tracing 'path' address 0x55a6d66deed0 to know how it is freed.
Breakpoint 2, _tc_free_children_internal (tc=0x55a6d66deed0, ptr=0x55a6d66def30, location=0x7fc4cca84040 "../../source3/rpc_server/mdssvc/srv_mdssvc_nt.c:189") at ../../lib/talloc/talloc.c:1656
1656 while (tc->child) {
(gdb) bt
0 _tc_free_children_internal (tc=0x55a6d66deed0, ptr=0x55a6d66def30, location=0x7fc4cca84040 "../../source3/rpc_server/mdssvc/srv_mdssvc_nt.c:189") at ../../lib/talloc/talloc.c:1656
1 0x00007fc4cb892b14 in _tc_free_internal (tc=0x55a6d66deed0, location=0x7fc4cca84040 "../../source3/rpc_server/mdssvc/srv_mdssvc_nt.c:189") at ../../lib/talloc/talloc.c:1183
2 0x00007fc4cb892cd5 in _talloc_free_internal (ptr=0x55a6d66def30, location=0x7fc4cca84040 "../../source3/rpc_server/mdssvc/srv_mdssvc_nt.c:189") at ../../lib/talloc/talloc.c:1247
3 0x00007fc4cb893f96 in _talloc_free (ptr=0x55a6d66def30, location=0x7fc4cca84040 "../../source3/rpc_server/mdssvc/srv_mdssvc_nt.c:189") at ../../lib/talloc/talloc.c:1791
4 0x00007fc4cc9396e4 in _mdssvc_open (p=0x55a6d66d5600, r=0x55a6d66edc60) at ../../source3/rpc_server/mdssvc/srv_mdssvc_nt.c:189
<...cut...>
Signed-off-by: Jones Syue <jonessyue@qnap.com>
Reviewed-by: Noel Power <npower@samba.org>
Reviewed-by: Volker Lendecke <vl@samba.org>
Autobuild-User(master): Noel Power <npower@samba.org>
Autobuild-Date(master): Mon Aug 14 18:11:37 UTC 2023 on atb-devel-224
(cherry picked from commit 044cb8f9d558bfcd7658cae0f05ff36330538748)
>>> CID 1539212: Control flow issues (NO_EFFECT)
>>> This greater-than-or-equal-to-zero comparison of an unsigned value is always true. "p >= 0UL".
216 while (p >= 0 && output[p] == '\n') {
This is a real problem in the unlikely event that the output contains
only newlines.
Fix the issue by using a pointer and add a test to cover this case.
BUG: https://bugzilla.samba.org/show_bug.cgi?id=15438
Signed-off-by: Martin Schwenke <mschwenke@ddn.com>
Reviewed-by: Amitay Isaacs <amitay@gmail.com>
(cherry picked from commit f01a179abcb33d9da6097f5ae45c7e7df1bc0397)
If a client opens multiple connection with the same
client guid in parallel, our connection passing is likely
to hit a race.
Assume we have 3 processes:
smbdA: This process already handles all connections for
a given client guid
smbdB: This just received a new connection with an
SMB2 neprot for the same client guid
smbdC: This also received a new connection with an
SMB2 neprot for the same client guid
Now both smbdB and smbdC send a MSG_SMBXSRV_CONNECTION_PASS
message to smbdA. These messages contain the socket fd
for each connection.
While waiting for a MSG_SMBXSRV_CONNECTION_PASSED message
from smbdA, both smbdB and smbdC watch the smbXcli_client.tdb
record for changes (that also verifies smbdA stays alive).
Once one of them say smbdB received the MSG_SMBXSRV_CONNECTION_PASSED
message, the dbwrap_watch logic will wakeup smbdC in order to
let it recheck the smbXcli_client.tdb record in order to
handle the case where smbdA died or deleted its record.
Now smbdC rechecks the smbXcli_client.tdb record, but it
was not woken because of a problem with smbdA. It meant
that smbdC sends a MSG_SMBXSRV_CONNECTION_PASS message
including the socket fd again.
As a result smbdA got the socket fd from smbdC twice (or even more),
and creates two (or more) smbXsrv_connection structures for the
same low level tcp connection. And it also sends more than one
SMB2 negprot response. Depending on the tevent logic, it will
use different smbXsrv_connection structures to process incoming
requests. And this will almost immediately result in errors.
The typicall error is:
smb2_validate_sequence_number: smb2_validate_sequence_number: bad message_id 2 (sequence id 2) (granted = 1, low = 1, range = 1)
But other errors would also be possible.
The detail that leads to the long delays on the client side is
that our smbd_server_connection_terminate_ex() code will close
only the fd of a single smbXsrv_connection, but the refcount
on the socket fd in the kernel is still not 0, so the tcp
connection is still alive...
Now we remember the server_id of the process that we send
the MSG_SMBXSRV_CONNECTION_PASS message to. And just keep
watching the smbXcli_client.tdb record if the server_id
don't change. As we just need more patience to wait for
the MSG_SMBXSRV_CONNECTION_PASSED message.
BUG: https://bugzilla.samba.org/show_bug.cgi?id=15346
Signed-off-by: Stefan Metzmacher <metze@samba.org>
Reviewed-by: Andreas Schneider <asn@samba.org>
Autobuild-User(master): Andreas Schneider <asn@cryptomilk.org>
Autobuild-Date(master): Tue Aug 8 13:59:58 UTC 2023 on atb-devel-224
(cherry picked from commit f348b84fbcf203ab1ba92840cf7aecd55dbf9aa0)
Autobuild-User(v4-19-test): Jule Anger <janger@samba.org>
Autobuild-Date(v4-19-test): Fri Aug 11 09:01:01 UTC 2023 on atb-devel-224
Commit 5d66d5b84f87267243dcd5223210906ce589af91 introduced a
'verify_again:' target, if we ever hit that, we would leak
the existing filter_subreq.
Moving it just above a possible messaging_filtered_read_send()
will allow us to only clear it if we actually create a new
request. That will help us in the next commits.
BUG: https://bugzilla.samba.org/show_bug.cgi?id=15346
Signed-off-by: Stefan Metzmacher <metze@samba.org>
Reviewed-by: Andreas Schneider <asn@samba.org>
(cherry picked from commit 50d61e5300250922bf36bb699306f82dff6a00b9)
This demonstrates the race quite easily against
Samba and works fine against Windows Server 2022.
BUG: https://bugzilla.samba.org/show_bug.cgi?id=15346
Signed-off-by: Stefan Metzmacher <metze@samba.org>
Reviewed-by: Andreas Schneider <asn@samba.org>
(cherry picked from commit 4028d6582907cf582730ceec56872d8584ad02e6)
BUG: https://bugzilla.samba.org/show_bug.cgi?id=15346
Signed-off-by: Stefan Metzmacher <metze@samba.org>
Reviewed-by: Andreas Schneider <asn@samba.org>
(cherry picked from commit 2b93058be3f6e5eaee239ad3b0e707c62089d18e)
BUG: https://bugzilla.samba.org/show_bug.cgi?id=15346
Signed-off-by: Stefan Metzmacher <metze@samba.org>
Reviewed-by: Andreas Schneider <asn@samba.org>
(cherry picked from commit dc5a500f0a76720b2a5cb5b1142cf4c35cb6bdea)
