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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
1. Set 'aio_allow_open' to false if fsp->fsp_flags.is_pathref
2. Move !(how->flags & O_CREAT) and !(how->flags & O_EXCL) up and set 'aio_allow_open' to false
3. Use SMB_VFS_NEXT_OPENAT() instead of openat() for disable async opens case.
BUG: https://bugzilla.samba.org/show_bug.cgi?id=15453
Signed-off-by: MikeLiu <mikeliu@qnap.com>
Reviewed-by: Stefan Metzmacher <metze@samba.org>
Reviewed-by: Jeremy Allison <jra@samba.org>
Autobuild-User(master): Jeremy Allison <jra@samba.org>
Autobuild-Date(master): Tue Aug 22 17:44:00 UTC 2023 on atb-devel-224
Autobuild-User(v4-18-test): Jule Anger <janger@samba.org>
Autobuild-Date(v4-18-test): Mon Sep 4 09:49:30 UTC 2023 on atb-devel-224
Remove knownfail.
BUG: https://bugzilla.samba.org/show_bug.cgi?id=15419
Signed-off-by: Jeremy Allison <jra@samba.org>
Reviewed-by: Ralph Boehme <slow@samba.org>
Autobuild-User(master): Ralph Böhme <slow@samba.org>
Autobuild-Date(master): Thu Jul 27 10:52:50 UTC 2023 on atb-devel-224
(cherry picked from commit 20df26b908182f0455f301a51aeb54b6044af580)
Autobuild-User(v4-18-test): Jule Anger <janger@samba.org>
Autobuild-Date(v4-18-test): Thu Aug 31 09:38:21 UTC 2023 on atb-devel-224
Fix a problem where ctdb_killtcp (almost always) fails to capture
packets with --enable-pcap and libpcap ≥ 1.9.1. The problem is due to
a gradual change in libpcap semantics when using
pcap_get_selectable_fd(3PCAP) to get a file descriptor and then using
that file descriptor in non-blocking mode.
pcap_set_immediate_mode(3PCAP) says:
pcap_set_immediate_mode() sets whether immediate mode should be set
on a capture handle when the handle is activated. In immediate
mode, packets are always delivered as soon as they arrive, with no
buffering.
and
On Linux, with previous releases of libpcap, capture devices are
always in immediate mode; however, in 1.5.0 and later, they are, by
default, not in immediate mode, so if pcap_set_immediate_mode() is
available, it should be used.
However, it wasn't until libpcap commit
2ade7676101366983bd4f86bc039ffd25da8c126 (before libpcap 1.9.1) that
it became a requirement to use pcap_set_immediate_mode(), even with a
timeout of 0.
More explanation in this libpcap issue comment:
https://github.com/the-tcpdump-group/libpcap/issues/860#issuecomment-541204548
Do a configure check for pcap_set_immediate_mode() even though it has
existed for 10 years. It is easy enough.
BUG: https://bugzilla.samba.org/show_bug.cgi?id=15451
Signed-off-by: Martin Schwenke <mschwenke@ddn.com>
Reviewed-by: Amitay Isaacs <amitay@gmail.com>
Autobuild-User(master): Amitay Isaacs <amitay@samba.org>
Autobuild-Date(master): Tue Aug 15 10:53:52 UTC 2023 on atb-devel-224
(cherry picked from commit dc7b48c404337891b5105df4d6751cf549a533eb)
Autobuild-User(v4-18-test): Jule Anger <janger@samba.org>
Autobuild-Date(v4-18-test): Tue Aug 29 12:27:35 UTC 2023 on atb-devel-224
A subsequent commit will insert an additional call before
pcap_activate().
This sequence of calls is taken from the source for pcap_open_live(),
so there should be no change in behaviour.
Given the defaults set by pcap_create_common(), it would be possible
to omit the calls to pcap_set_promisc() and pcap_set_timeout().
However, those defaults don't seem to be well documented, so continue
to explicitly set everything that was set before.
BUG: https://bugzilla.samba.org/show_bug.cgi?id=15451
Signed-off-by: Martin Schwenke <mschwenke@ddn.com>
Reviewed-by: Amitay Isaacs <amitay@gmail.com>
(cherry picked from commit ffc2ae616d8fab7528fbdfd8c6b94c5b9a0e3a7c)
Factor out a failure label, which will get more use in subsequent
commits, and only set private_data when success is certain.
BUG: https://bugzilla.samba.org/show_bug.cgi?id=15451
Signed-off-by: Martin Schwenke <mschwenke@ddn.com>
Reviewed-by: Amitay Isaacs <amitay@gmail.com>
(cherry picked from commit d87041d8968e91db9d257445321b85693303f95e)
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-18-test): Jule Anger <janger@samba.org>
Autobuild-Date(v4-18-test): Mon Aug 21 09:12:14 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
(Back-ported from commit 4145bfb1b5a3639caf26a310d612aec29fc00117)
Autobuild-User(v4-18-test): Jule Anger <janger@samba.org>
Autobuild-Date(v4-18-test): Fri Aug 18 14:07:39 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>
(Back-ported 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>
(Back-ported from commit f02f74e931f5821c7b7c1be2b8f0fb60c9a69b19)
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-18-test): Jule Anger <janger@samba.org>
Autobuild-Date(v4-18-test): Wed Aug 16 11:49:39 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)
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-18-test): Jule Anger <janger@samba.org>
Autobuild-Date(v4-18-test): Fri Aug 11 09:49:53 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)
There's no need for smb2_connect_ext().
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 ade663ee6ca1a2813b203ea667d933f4dab9e7b7)
It seems commit 259129e8f4bc8cacd1850eba3f6551134835d079 was partly just
fantasy...
Windows clients just use 16 bytes for DCERPC_PKT_CO_CANCEL and
DCERPC_PKT_ORPHANED pdus.
BUG: https://bugzilla.samba.org/show_bug.cgi?id=15446
Signed-off-by: Stefan Metzmacher <metze@samba.org>
Reviewed-by: Volker Lendecke <vl@samba.org>
Autobuild-User(master): Volker Lendecke <vl@samba.org>
Autobuild-Date(master): Tue Aug 8 08:57:46 UTC 2023 on atb-devel-224
(cherry picked from commit 9ec22e680249cfde06fb1a0a34fcc94d1f47002d)
Autobuild-User(v4-18-test): Jule Anger <janger@samba.org>
Autobuild-Date(v4-18-test): Tue Aug 8 12:56:30 UTC 2023 on atb-devel-224
DCERPC_PKT_CO_CANCEL and DCERPC_PKT_ORPHANED don't have any payload by
default. In order to receive them via dcerpc_read_ncacn_packet_send/recv
we need to allow fragments with frag_len == DCERPC_NCACN_PAYLOAD_OFFSET.
BUG: https://bugzilla.samba.org/show_bug.cgi?id=15446
Signed-off-by: Stefan Metzmacher <metze@samba.org>
Reviewed-by: Volker Lendecke <vl@samba.org>
(cherry picked from commit 5c724a3e156ae734e4d187bf9639d895bb011834)
The PDUs were generated by Windows clients.
And we fail to parse them currently.
BUG: https://bugzilla.samba.org/show_bug.cgi?id=15446
Signed-off-by: Stefan Metzmacher <metze@samba.org>
Reviewed-by: Volker Lendecke <vl@samba.org>
(cherry picked from commit c37adb762640b7df9731d6a60edce808aa8787f8)
If configured as AD DC and aio_pthread appended into 'vfs objects'[1],
run these commands would get segfault:
1. sudo samba-tool ntacl get .
2. sudo net vfs getntacl sysvol .
gdb said it goes through aio_pthread_openat_fn() @ vfs_aio_pthread.c[2],
and the fsp->conn->sconn->client is null (0x0).
'sconn->client' memory is allocated when a new connection is accpeted:
smbd_accept_connection > smbd_process > smbXsrv_client_create
While running local commands looks like it would not go through
smbXsrv_client_create so the 'client' is null, segfault might happen.
We should not dereference 'client->server_multi_channel_enabled',
if 'client' is null.
BUG: https://bugzilla.samba.org/show_bug.cgi?id=15441
[1] smb.conf example, samba-4.18.5, ubuntu 22.04.2
[global]
dns forwarder = 127.0.0.53
netbios name = U22-JONES-88X1
realm = U22-JONES-88X1.X88X1.JONES
server role = active directory domain controller
workgroup = X88X1
idmap_ldb:use rfc2307 = yes
vfs objects = dfs_samba4 acl_xattr aio_pthread
[sysvol]
path = /var/lib/samba/sysvol
read only = No
[netlogon]
path = /var/lib/samba/sysvol/u22-jones-88x1.x88x1.jones/scripts
read only = No
[2] gdb
(gdb) run /usr/local/samba/bin/samba-tool ntacl get .
Starting program: /usr/local/Python3/bin/python3 /usr/local/samba/bin/samba-tool ntacl get .
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/libthread_db.so.1".
Program received signal SIGSEGV, Segmentation fault.
0x00007fffd0eb809e in aio_pthread_openat_fn (handle=0x8d5cc0, dirfsp=0x8c3070, smb_fname=0x18ab4f0, fsp=0x1af3550, flags=196608, mode=0)
at ../../source3/modules/vfs_aio_pthread.c:467
warning: Source file is more recent than executable.
467 if (fsp->conn->sconn->client->server_multi_channel_enabled) {
(gdb) bt
at ../../source3/modules/vfs_aio_pthread.c:467
at ../../source3/smbd/pysmbd.c:320
---Type <return> to continue, or q <return> to quit---
(gdb) f
at ../../source3/modules/vfs_aio_pthread.c:467
467 if (fsp->conn->sconn->client->server_multi_channel_enabled) {
(gdb) p fsp->conn->sconn->client
$1 = (struct smbXsrv_client *) 0x0
(gdb)
Signed-off-by: Jones Syue <jonessyue@qnap.com>
Reviewed-by: Ralph Boehme <slow@samba.org>
Reviewed-by: Stefan Metzmacher <metze@samba.org>
(cherry picked from commit 8f4c1c67b4f118a9a47b09ac7908cd3d969b19c2)
During 'samba-tool ntacl sysvolreset' and similar.
BUG: https://bugzilla.samba.org/show_bug.cgi?id=15441
Signed-off-by: Stefan Metzmacher <metze@samba.org>
Reviewed-by: Andrew Bartlett <abartlet@samba.org>
(cherry picked from commit 3694f2ce6205a647eb5dab2115785fb45decaf0b)
BUG: https://bugzilla.samba.org/show_bug.cgi?id=15289
Signed-off-by: Andrew Bartlett <abartlet@samba.org>
Reviewed-by: Douglas Bagnall <douglas.bagnall@catalyst.net.nz>
Autobuild-User(master): Andrew Bartlett <abartlet@samba.org>
Autobuild-Date(master): Fri Jul 21 06:16:30 UTC 2023 on atb-devel-224
(cherry picked from commit 76ad44f446c42832e87b2c60a4731a8de3a0018f)
RN: post-exec password redaction for samba-tool is more reliable for
fully random passwords as it no longer uses regular expressions
containing the password value itself.
Autobuild-User(v4-18-test): Jule Anger <janger@samba.org>
Autobuild-Date(v4-18-test): Fri Aug 4 08:05:00 UTC 2023 on atb-devel-224
