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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
Accessing the wrong member of a union invokes undefined behaviour.
Signed-off-by: Joseph Sutton <josephsutton@catalyst.net.nz>
Reviewed-by: Andrew Bartlett <abartlet@samba.org>
Also, correctly format the value as unsigned.
Signed-off-by: Joseph Sutton <josephsutton@catalyst.net.nz>
Reviewed-by: Andrew Bartlett <abartlet@samba.org>
Signed-off-by: Andreas Schneider <asn@samba.org>
Reviewed-by: Joseph Sutton <josephsutton@catalyst.net.nz>
Autobuild-User(master): Andrew Bartlett <abartlet@samba.org>
Autobuild-Date(master): Mon Aug 14 04:40:03 UTC 2023 on atb-devel-224
This is the version we test with in CI after the image update
in the next commit. This addresses the issues that were
fixed in CVE-2022-37967 (KrbtgtFullPacSignature) and ensures
that Samba builds against the MIT version that allows us to
avoid that attack.
The hooks to allow these expectations to be disabled in the tests
are kept for now, to allow this to be reverted or to test
older servers.
With MIT 1.21 as the new test standard for the MIT KDC build
we update the knownfail_mit_kdc - this was required regadless
after the CI image update.
Any update to the CI image, even an unrelated one, brings in
a new MIT Krb5, version 1.21-3 in this case. This has new
behaviour that needs to be noted in the knownfail files or
else the tests, which haven't changed, will fail and
pipelines won't pass.
(The image generated by the earlier bootstrap commit brought
in krb5-1.21-2 which was buggy with CVE-2023-39975)
Further tweaks to tests or the server should reduce the number
of knownfail entries, but this keeps the pipelines passing for now.
BUG: https://bugzilla.samba.org/show_bug.cgi?id=15231
Signed-off-by: Andrew Bartlett <abartlet@samba.org>
Reviewed-by: Joseph Sutton <josephsutton@catalyst.net.nz>
This is the simplest way to keep this test environment alive.
Signed-off-by: Andrew Bartlett <abartlet@samba.org>
Reviewed-by: Joseph Sutton <josephsutton@catalyst.net.nz>
Heimdal after lorikeet-heimdal-202307040259
(commit 33d117b8a9c11714ef709e63a005d87e34b9bfde)
includes Heimdal master commit f62e2f278437ff6c03d2d09bd628381c795bba78.
This has PR https://github.com/heimdal/heimdal/pull/1176 and no
longer requires the external JSON module, as JSON::PP is builtin.
BUG: https://bugzilla.samba.org/show_bug.cgi?id=15394
Signed-off-by: Andrew Bartlett <abartlet@samba.org>
Reviewed-by: Joseph Sutton <josephsutton@catalyst.net.nz>
We do not normally put the ==== above the titles, per recent practice.
Signed-off-by: Andrew Bartlett <abartlet@samba.org>
Reviewed-by: Joseph Sutton <josephsutton@catalyst.net.nz>
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Reviewed-by: Andrew Bartlett <abartlet@samba.org>
Reviewed-by: Volker Lendecke <vl@samba.org>
Autobuild-User(master): Andrew Bartlett <abartlet@samba.org>
Autobuild-Date(master): Sun Aug 13 22:54:55 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.
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
This check was valuable before aee2039e63
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>
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>
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>
If we hit a reparse point in point, it might be something but a
symlink.
Signed-off-by: Volker Lendecke <vl@samba.org>
Reviewed-by: Jeremy Allison <jra@samba.org>
Autobuild-User(master): Stefan Metzmacher <metze@samba.org>
Autobuild-Date(master): Thu Aug 10 14:36:40 UTC 2023 on atb-devel-224
Eventually we'll have to make STOPPED_ON_SYMLINK special to handle the
symlink response, but for now they are the same.
STOPPED_ON_SYMLINK will tell us where the symlink is,
REPARSE_TAG_NOT_HANDLED won't. So if there's an unhandled reparse
point somewhere in the path, there's no really good way to handle
this. We'll get the REPARSE_TAG_NOT_HANDLED the second time as
well. Even SMB1 QPATHINFO gets this when you try to cross a NFS
reparse point.
Signed-off-by: Volker Lendecke <vl@samba.org>
Reviewed-by: Jeremy Allison <jra@samba.org>
Will be used in smbclient's allinfo command: Reparse points are more
than just symlinks.
Signed-off-by: Volker Lendecke <vl@samba.org>
Reviewed-by: Jeremy Allison <jra@samba.org>
The goal of this is to eventually remove reparse_symlink.c once we
have marshalling routines for symlinks in reparse.c
Signed-off-by: Volker Lendecke <vl@samba.org>
Reviewed-by: Jeremy Allison <jra@samba.org>
Remove the last direct caller of symlink_reparse_buffer_parse()
Signed-off-by: Volker Lendecke <vl@samba.org>
Reviewed-by: Jeremy Allison <jra@samba.org>
When we retrieve reparse point data, we don't know before what we
get. Right now all we do is expect a symlink, but we could get other
types as well.
Signed-off-by: Volker Lendecke <vl@samba.org>
Reviewed-by: Jeremy Allison <jra@samba.org>
If you run "allinfo" on a symlink with NT1, cli_readlink_send sends a
NULL "in" blob. Do the same as smb2cli_ioctl_send() does, just send
NULL/0 in that case and don't crash.
Signed-off-by: Volker Lendecke <vl@samba.org>
Reviewed-by: Jeremy Allison <jra@samba.org>
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
Commit 5d66d5b84f 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>
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>
