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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
This test checks the SMB 2.1.0 behaviour of lock sequence checking,
which is only turned on for resilient handles.
Even Windows Server 2019 only implements lock sequence checking only
for resilient and persistent handles as a server.
While its client side uses lock sequence checking if it negotiated
multichannel with the server.
Hopefully this will be fixed in future Windows versions.
Make it clear that this test is supposed to pass against the legacy
Windows servers which violate the specification:
[MS-SMB2] 3.3.5.14 Receiving an SMB2 LOCK Request
...
... if Open.IsResilient or Open.IsDurable or Open.IsPersistent is
TRUE or if Connection.Dialect belongs to the SMB 3.x dialect family
and Connection.ServerCapabilities includes
SMB2_GLOBAL_CAP_MULTI_CHANNEL bit, the server SHOULD<314>
perform lock sequence verification ...
...
<314> Section 3.3.5.14: Windows 7 and Windows Server 2008 R2 perform
lock sequence verification only when Open.IsResilient is TRUE.
Windows 8 through Windows 10 v1909 and Windows Server 2012 through
Windows Server v1909 perform lock sequence verification only when
Open.IsResilient or Open.IsPersistent is TRUE.
Note <314> also applies to all versions (at least) up to Windows Server v2004.
Hopefully this will be fixed in future Windows versions and they
will avoid Note <314>.
Signed-off-by: Stefan Metzmacher <metze@samba.org>
Reviewed-by: Jeremy Allison <jra@samba.org>
The test was wrong in that it used an invalid
lock sequence bucket (65) where it actually wanted
to use a valid on (64), and hence the test results
(which were adapted to the real responses) were not
quite logical.
This patch fixes this and also improves some of
the comments so that the flow of the patch becomes
a little more obvious.
Pair-Programmed-With: Günther Deschner <gd@samba.org>
Signed-off-by: Michael Adam <obnox@samba.org>
Signed-off-by: Günther Deschner <gd@samba.org>
Reviewed-by: Stefan Metzmacher <metze@samba.org>
Reviewed-by: Jeremy Allison <jra@samba.org>
Because this test returned true, it would always
succeed, despite failures in the test. Make it
return false if there are failures. Also, removed
a stray CHECK_MAX_FAILURES introduced by commit
8773e743 that caused the test to *always* fail
(but always be ignored).
Signed-off-by: David Mulder <dmulder@suse.com>
Reviewed-by: Isaac Boukris <iboukris@samba.org>
Autobuild-User(master): David Mulder <dmulder@samba.org>
Autobuild-Date(master): Wed Jun 24 22:13:11 UTC 2020 on sn-devel-184
We should use the default priority list. That is a good practice,
because TLS protocol hardening and phasing out of legacy algorithms,
is easier to co-ordinate when happens at a single place. See crypto
policies of Fedora.
BUG: https://bugzilla.samba.org/show_bug.cgi?id=14408
Signed-off-by: Andreas Schneider <asn@samba.org>
Reviewed-by: Alexander Bokovoy <ab@samba.org>
Autobuild-User(master): Andreas Schneider <asn@cryptomilk.org>
Autobuild-Date(master): Wed Jun 17 17:42:02 UTC 2020 on sn-devel-184
If we go to done and call smbc_free_context() the pointer should be
initialized.
Found by clang.
Signed-off-by: Andreas Schneider <asn@samba.org>
Reviewed-by: Isaac Boukris <iboukris@samba.org>
it has been a long time since we introduced "control", so lets remind
ourselves which control it was.
Signed-off-by: Douglas Bagnall <douglas.bagnall@catalyst.net.nz>
Reviewed-by: Andrew Bartlett <abartlet@samba.org>
Autobuild-User(master): Andrew Bartlett <abartlet@samba.org>
Autobuild-Date(master): Sat Jun 13 06:50:12 UTC 2020 on sn-devel-184
BUG: https://bugzilla.samba.org/show_bug.cgi?id=14233
Match Windows behavior and allow the forwardable flag to be
set in cross-realm tickets. We used to allow forwardable to
any server, but now that we apply disallow-forwardable policy
in heimdal we need to explicitly allow in the corss-realm case
(and remove the workaround we have for it the MIT plugin).
Signed-off-by: Isaac Boukris <iboukris@samba.org>
Reviewed-by: Andreas Schneider <asn@samba.org>
Reviewed-by: Andrew Bartlett <abartlet@samba.org>
Autobuild-User(master): Andrew Bartlett <abartlet@samba.org>
Autobuild-Date(master): Fri Jun 12 22:10:34 UTC 2020 on sn-devel-184
BUG: https://bugzilla.samba.org/show_bug.cgi?id=14233
Signed-off-by: Isaac Boukris <iboukris@samba.org>
Reviewed-by: Andreas Schneider <asn@samba.org>
Reviewed-by: Andrew Bartlett <abartlet@samba.org>
even if the tgt session key uses different hmac.
Per [MS-SFU] 2.2.1 PA-FOR-USER the checksum is
always HMAC_MD5, and that's what windows 7 client
and MIT client send.
In heimdal both the client and kdc use the checksum of
the tgt key instead and therefore work with each other
but windows and MIT clients fail against heimdal KDC.
Windows KDC allows either checksum (HMAC_MD5 or from
tgt) so we should do the same to support all clients.
Signed-off-by: Isaac Boukris <iboukris@samba.org>
Reviewed-by: Andrew Bartlett <abartlet@samba.org>
Autobuild-User(master): Andrew Bartlett <abartlet@samba.org>
Autobuild-Date(master): Thu Jun 11 02:48:58 UTC 2020 on sn-devel-184
We test the limits here and leave a 16TB file with zeros.
BUG: https://bugzilla.samba.org/show_bug.cgi?id=14361
Signed-off-by: Stefan Metzmacher <metze@samba.org>
Reviewed-by: Ralph Boehme <slow@samba.org>
Autobuild-User(master): Stefan Metzmacher <metze@samba.org>
Autobuild-Date(master): Fri Jun 5 13:17:55 UTC 2020 on sn-devel-184
Used to fill the unix info in a struct auth_session_info similar to
auth_session_info_fill_unix().
The new auth_session_info_set_unix() receives the uid and gid for
the unix token as an parameter. It does not query the unix token from
winbind (via security_token_to_unix_token()).
This is useful to fill a user session info manually if winbind is not
available.
Bug: https://bugzilla.samba.org/show_bug.cgi?id=14400
Signed-off-by: Björn Baumbach <bb@sernet.de>
Reviewed-by: Ralph Boehme <slow@samba.org>
The test is written for SAMR, but as the handle type is verified by the
server core library it also applies to other RPC services.
Signed-off-by: Samuel Cabrero <scabrero@samba.org>
Reviewed-by: Andrew Bartlett <abartlet@samba.org>
Pair-Programmed-With: Anoop C S <anoopcs@redhat.com>
Signed-off-by: Michael Adam <obnox@samba.org>
Reviewed-by: Guenther Deschner <gd@samba.org>
Autobuild-User(master): Günther Deschner <gd@samba.org>
Autobuild-Date(master): Fri May 15 16:02:47 UTC 2020 on sn-devel-184
To test the CRC32 I reverted the unkeyed-checksum fix (43958af1)
and the weak-crypto fix (389d1b97). Note that the unkeyed-md5
still worked even with weak-crypto disabled, and that the
unkeyed-sha1 never worked but I left it anyway.
Signed-off-by: Isaac Boukris <iboukris@samba.org>
Reviewed-by: Andrew Bartlett <abartlet@samba.org>
Autobuild-User(master): Andrew Bartlett <abartlet@samba.org>
Autobuild-Date(master): Fri May 15 12:25:40 UTC 2020 on sn-devel-184
This reverts commit 5639e973c1f6f1b28b122741763f1d05b47bc2d8.
This is no longer needed as the next commit includes a Python
test for this, without the complexity of being inside krb5.kdc.canon.
Signed-off-by: Isaac Boukris <iboukris@samba.org>
Reviewed-by: Andrew Bartlett <abartlet@samba.org>
This reverts commit 151f8c0f31d3d17b9418db3793ec14ba7dbf2143.
This allows a clean revert (and so removal) of the test.
Signed-off-by: Isaac Boukris <iboukris@samba.org>
Reviewed-by: Andrew Bartlett <abartlet@samba.org>
This reverts commit a53fa8ffe3e36f7921baf5d31a1052747f90aa7d.
This allows a clean revert (and so removal) of the test.
Signed-off-by: Isaac Boukris <iboukris@samba.org>
Reviewed-by: Andrew Bartlett <abartlet@samba.org>
On (eg) the
DC=_msdcs.X.Y,CN=MicrosoftDNS,DC=ForestDnsZones,DC=X,DC=Y
record, in domains that have had a Microsoft Windows DC an attribute:
dNSProperty:: AAAAAAAAAAAAAAAAAQAAAJIAAAAAAAAA
000000 00 00 00 00 00 00 00 00 00 00 00 00 01 00 00 00 >................<
000010 92 00 00 00 00 00 00 00 >........<
000018
We, until samba 4.12, would parse this as:
pull returned Success
dnsp_DnsProperty: struct dnsp_DnsProperty
wDataLength : 0x00000000 (0)
namelength : 0x00000000 (0)
flag : 0x00000000 (0)
version : 0x00000001 (1)
id : DSPROPERTY_ZONE_NS_SERVERS_DA (146)
data : union dnsPropertyData(case 0)
name : 0x00000000 (0)
dump OK
However, the wDataLength is 0. There is not anything in
[MS-DNSP] 2.3.2.1 dnsProperty to describe any special behaviour
for when the id suggests that there is a value, but wDataLength is 0.
https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-dnsp/445c7843-e4a1-4222-8c0f-630c230a4c80
We now fail to parse it, because we expect an entry with id DSPROPERTY_ZONE_NS_SERVERS_DA
to therefore have a valid DNS_ADDR_ARRAY (section 2.2.3.2.3).
As context we changed it in our commit fee5c6a4247aeac71318186bbff7708d25de5912
because of bug https://bugzilla.samba.org/show_bug.cgi?id=14206
which was due to the artificial environment of the fuzzer.
Microsoft advises that Windows also fails to parse this, but
instead of failing the operation, the value is ignored.
Reported by Alex MacCuish. Many thanks for your assistance in
tracking down the issue.
BUG: https://bugzilla.samba.org/show_bug.cgi?id=14310
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 May 15 07:29:17 UTC 2020 on sn-devel-184
raw.samba3rootdirfid tests with the share root directory as root_dir_fid handle,
that doesn't cover the case where the relative name has more then one path
component. It only works because in unix_convert() we run into the creating file
optimasation.
BUG: https://bugzilla.samba.org/show_bug.cgi?id=14380
Signed-off-by: Ralph Boehme <slow@samba.org>
Reviewed-by: Jeremy Allison <jra@samba.org>
[MS-FSA] 2.1.5.2 Server Requests a Read and
2.1.5.3 Server Requests a Write define some contraints.
These tests demonstrate that ((int64_t)offset) < 0) is
not allowed for both reads and writes for SMB.
Also the special case for writes at offset -2 is not possible
nor the append mode with offset < 0.
BUG: https://bugzilla.samba.org/show_bug.cgi?id=14361
Signed-off-by: Stefan Metzmacher <metze@samba.org>
Reviewed-by: Jeremy Allison <jra@samba.org>
Review-note: The for loop increment operation was changed and the
trailing i++ was removed from the loop body.
The resulting for statement is equivalent to the original
Signed-off-by: Gary Lockyer <gary@catalyst.net.nz>
Reviewed-by: Andreas Schneider <asn@samba.org>
Autobuild-User(master): Andreas Schneider <asn@cryptomilk.org>
Autobuild-Date(master): Fri May 8 11:16:18 UTC 2020 on sn-devel-184
Opens the root of a share over SMB2 with a zero-length
filename and a timewarp token.
Signed-off-by: Jeremy Allison <jra@samba.org>
Reviewed-by: Ralph Boehme <slow@samba.org>
