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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
We just destroy the signature bytes but keep the header unchanged.
This makes it easier to look at it in wireshark.
BUG: https://bugzilla.samba.org/show_bug.cgi?id=13019
Signed-off-by: Stefan Metzmacher <metze@samba.org>
Reviewed-by: Andrew Bartlett <abartlet@samba.org>
These libraries, mostly with ABI versions of 0.0.1 were made public in
the early development of Samba4 and have not been seriously considered
since. Most are to allow OpenChange to build.
While the OpenChange server is no longer actively used, the MAPI
client is used and we need to allow packages to be built that will
allow the Evolution MAPI client to still work.
Some appear to be mistakes (dcerpc-samr), historical abberations
(tevent-util) or ideas that did not go very far (the samba-policy
library for example).
To allow any remaining users to access them, they are not made private
in the build system but are instead listed so that they can be made
public again via ./configure with the same --private-libraries='!LIB'
syntax introduced to make ldb private by default.
Signed-off-by: Andrew Bartlett <abartlet@samba.org>
Reviewed-by: Alexander Bokovoy <ab@samba.org>
Autobuild-User(master): Andrew Bartlett <abartlet@samba.org>
Autobuild-Date(master): Wed Jun 5 21:47:24 UTC 2024 on atb-devel-224
This is a normal C library, used by python but does not use
any python itself (nor by dependencies any longer).
Signed-off-by: Andrew Bartlett <abartlet@samba.org>
Reviewed-by: Alexander Bokovoy <ab@samba.org>
samba-net-join links to python and so needs the variable name
with the python ABI tag, while samba-net is a normal C library
and can be included in a package without python dependencies.
Signed-off-by: Andrew Bartlett <abartlet@samba.org>
Reviewed-by: Alexander Bokovoy <ab@samba.org>
If this test happens to be run in the five minute window prior to the
next ten‐hour GKDI interval — about once every one hundred and twenty
runs — the ‘current’ password requested from LDAP will actually be the
future password, which won’t match what’s in the database.
Instead of taking the password from LDAP, calculate it ourselves with
expected_gmsa_password_blob().
[330(7038)/334 at 43m51s] samba.tests.krb5.gmsa_tests(ad_dc:local)
UNEXPECTED(failure): samba.tests.krb5.gmsa_tests.samba.tests.krb5.gmsa_tests.GmsaTests.test_retrieving_managed_password_triggers_keys_update(ad_dc:local)
REASON: Exception: Exception: Traceback (most recent call last):
File "/builds/samba-testbase/samba-def-build/bin/python/samba/tests/krb5/gmsa_tests.py", line 1091, in test_retrieving_managed_password_triggers_keys_update
self.assertEqual(creds.get_nt_hash(), nt_hash)
AssertionError: b'\xcf[\xe8:\xc7-\xd4V\xce\t\xfc\xcd\x06.T\x8a' != b'c\xc5\x97k\x17"G\x1e\x81>\xacV\x9d.*\x14'
Signed-off-by: Jo Sutton <josutton@catalyst.net.nz>
Reviewed-by: Andrew Bartlett <abartlet@samba.org>
Autobuild-User(master): Andrew Bartlett <abartlet@samba.org>
Autobuild-Date(master): Tue Jun 4 20:52:09 UTC 2024 on atb-devel-224
In case of a trusted domain, we are providing the realm of the primary
trust but specify the KDC IP of the trusted domain. This leads to
Kerberos ticket requests to the trusted domain KDC which doesn't know
about the machine account. However we need a ticket from our primary
trust KDC.
BUG: https://bugzilla.samba.org/show_bug.cgi?id=15653
Signed-off-by: Andreas Schneider <asn@samba.org>
Reviewed-by: Andrew Bartlett <abartlet@samba.org>
The IP should be optional and we should look it up if not provided.
BUG: https://bugzilla.samba.org/show_bug.cgi?id=15653
Signed-off-by: Andreas Schneider <asn@samba.org>
Reviewed-by: Andrew Bartlett <abartlet@samba.org>
Remove the requirement to provide an IP address. We should look up the
IP of the KDC and use it for the specified realm/workgroup.
BUG: https://bugzilla.samba.org/show_bug.cgi?id=15653
Signed-off-by: Andreas Schneider <asn@samba.org>
Reviewed-by: Andrew Bartlett <abartlet@samba.org>
Signed-off-by: Volker Lendecke <vl@samba.org>
Reviewed-by: Jeremy Allison <jra@samba.org>
Autobuild-User(master): Jeremy Allison <jra@samba.org>
Autobuild-Date(master): Tue Jun 4 17:39:21 UTC 2024 on atb-devel-224
With the source3/ based clilist.c, we can't test all infolevels where
this matters (see callers of get_dirent_ea_size()). But porting the
source4 based all-infolevel search code into source3/libsmb or doing
this one the reparse point test in the source4 infrastructure to me
seems like a lot of effort for moderate gain.
Signed-off-by: Volker Lendecke <vl@samba.org>
Reviewed-by: Jeremy Allison <jra@samba.org>
BUG: https://bugzilla.samba.org/show_bug.cgi?id=15465
Signed-off-by: Jo Sutton <josutton@catalyst.net.nz>
Reviewed-by: Noel Power <noel.power@suse.com>
Autobuild-User(master): Noel Power <npower@samba.org>
Autobuild-Date(master): Tue Jun 4 09:39:42 UTC 2024 on atb-devel-224
Change levels tested from 1 - 3 to 1 - 4 for NETLOGON_CONTROL_SET_DBFLAG
This change triggers a core dump in the server and so we add a knownfail
here. Following commit will fix (and remove known fail)
BUG: https://bugzilla.samba.org/show_bug.cgi?id=15465
Signed-off-by: Noel Power <noel.power@suse.com>
Reviewed-by: Douglas Bagnall <douglas.bagnall@catalyst.net.nz>
A future (next) commit will change the NETLOGON_CONTROL_SET_DBFLAG test
to use levels 1 - 4 (current test just tests 1 - 3). A side affect of
this test is that the following test will now test passing an unknown
function code against against Level 4 (previously level 3).
Unfortunately s4 and s3 netlogon server results differ when handling
a level 4 request with an unknown function code.
s3 server returns WERR_NOT_SUPPORTED and
s4 server returns WERR_INVALID_PARAMETER.
For level 3 both return WERR_NOT_SUPPORTED.
MS-NRPC doesn't seem to specifically indicate the required response in
this case.
this commit modifies the test to cater for either response (for either
level) A future commit could explore the test response combinations more
thorougly.
BUG: https://bugzilla.samba.org/show_bug.cgi?id=15465
Signed-off-by: Noel Power <noel.power@suse.com>
Reviewed-by: Douglas Bagnall <douglas.bagnall@catalyst.net.nz>
We don't need that intermediate talloc ctx, we only allocate backends
and don't pass it anywhere else.
Signed-off-by: Volker Lendecke <vl@samba.org>
Reviewed-by: Andrew Bartlett <abartlet@samba.org>
Every single caller of gensec_security_mechs() had to manually filter
out disabled mechanisms. Don't offer them from the start.
Signed-off-by: Volker Lendecke <vl@samba.org>
Reviewed-by: Andrew Bartlett <abartlet@samba.org>
The decision whether to offer a mechanism was split between
gensec_security_mechs() and gensec_use_kerberos_mechs() with two
booleans passed down. Consolidate that decision into one
gensec_offer_mech() function that queries all information on its own.
Signed-off-by: Volker Lendecke <vl@samba.org>
Reviewed-by: Andrew Bartlett <abartlet@samba.org>
In this case a nested if seems easier to understand to me than another
if-expression duplicating half of a previous one.
Signed-off-by: Volker Lendecke <vl@samba.org>
Reviewed-by: Andrew Bartlett <abartlet@samba.org>
Previously we added an implementation for SMB_VFS_FGET_DOS_ATTRIBUTES
so that the btime is always preserved unless explicitly changed using
SMB_VFS_FNTIMES. But there are situations with open file handle where
btime stored on dos attributes as create_time has to be precise for
comparison because a one-to-one conversion between timepsec and nttime
is not always guaranteed.
Accordingly preserve btime via SMB_VFS_FSET_DOS_ATTRIBUTES so that we
always compare the exact btime from fsp stat information while the file
handle is still open.
Signed-off-by: Anoop C S <anoopcs@samba.org>
Reviewed-by: David Disseldorp <ddiss@samba.org>
Autobuild-User(master): Anoop C S <anoopcs@samba.org>
Autobuild-Date(master): Mon Jun 3 11:10:11 UTC 2024 on atb-devel-224
We insert 999 keys, but if two of them happen to be the same, we
don't find 1000 nodes, and that is upsetting for CI:
[130(1421)/303 at 4m46s] samba3.smbtorture_s3.LOCAL-RBTREE
UNEXPECTED(failure): samba3.smbtorture_s3.LOCAL-RBTREE.smbtorture(none)
REASON: Exception: Exception: using seed 1716333987
host=foo share=bar user= myname=runner-jlguopmm-project-6378020-concurrent-0
Running LOCAL-RBTREE
run_local_rbtree: read1: 999 999, NT_STATUS_OK
run_local_rbtree: delete: 999 999, NT_STATUS_OK
run_local_rbtree: read2: 0 0, NT_STATUS_OK
TEST LOCAL-RBTREE FAILED!
LOCAL-RBTREE took 0.002706 secs
This has been flapping very occasionally for a long time:
https://lists.samba.org/archive/samba-technical/2016-March/112861.html
Signed-off-by: Douglas Bagnall <douglas.bagnall@catalyst.net.nz>
Reviewed-by: Andrew Bartlett <abartlet@samba.org>
Reviewed-by: Volker Lendecke <vl@samba.org>
It turns out the timestamp doesn't need to be real, and it isn't used,
but it might as well tell you something. So let's make it tell you what
version of Samba it came from, which could be useful for people who have
lots of old winexes lying around, the poor souls.
00000040 0e 1f ba 0e 00 b4 09 cd 21 b8 01 4c cd 21 54 68 |........!..L.!Th|
00000050 69 73 20 70 72 6f 67 72 61 6d 20 63 61 6e 6e 6f |is program canno|
00000060 74 20 62 65 20 72 75 6e 20 69 6e 20 44 4f 53 20 |t be run in DOS |
00000070 6d 6f 64 65 2e 0d 0d 0a 24 00 00 00 00 00 00 00 |mode....$.......|
00000080 50 45 00 00 64 86 0a 00 00 15 04 00 00 00 00 00 |PE..d...........|
| | |
| | major 4.
| minor 21.
release 0
BUG: https://bugzilla.samba.org/show_bug.cgi?id=13213
Signed-off-by: Douglas Bagnall <douglas.bagnall@catalyst.net.nz>
Reviewed-by: Andrew Bartlett <abartlet@samba.org>
Autobuild-User(master): Douglas Bagnall <dbagnall@samba.org>
Autobuild-Date(master): Fri May 31 01:28:06 UTC 2024 on atb-devel-224
Windows Portable Executable files have a timestamp field and a
checksum field. By default the timestamp field is updated to the
current time, which consequently changes the checksum. This makes the
build nondeterministic. It looks like this:
--- a/tmp/winexe-1/winexesvc64_exe_binary.c
+++ b/tmp/winexe-2/winexesvc64_exe_binary.c
@@ -23,7 +23,7 @@ const DATA_BLOB *winexesvc64_exe_binary(void)
0x6D, 0x6F, 0x64, 0x65, 0x2E, 0x0D, 0x0D, 0x0A,
0x24, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
0x50, 0x45, 0x00, 0x00, 0x64, 0x86, 0x0A, 0x00,
- 0xB2, 0x16, 0x55, 0x66, 0x00, 0x00, 0x00, 0x00,
+ 0xD3, 0x3B, 0x55, 0x66, 0x00, 0x00, 0x00, 0x00,
0x00, 0x00, 0x00, 0x00, 0xF0, 0x00, 0x2E, 0x02,
0x0B, 0x02, 0x02, 0x26, 0x00, 0x86, 0x00, 0x00,
0x00, 0xBA, 0x00, 0x00, 0x00, 0x0C, 0x00, 0x00,
@@ -33,7 +33,7 @@ const DATA_BLOB *winexesvc64_exe_binary(void)
0x04, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
0x05, 0x00, 0x02, 0x00, 0x00, 0x00, 0x00, 0x00,
0x00, 0x40, 0x01, 0x00, 0x00, 0x04, 0x00, 0x00,
- 0x73, 0xD7, 0x00, 0x00, 0x03, 0x00, 0x60, 0x01,
+ 0x94, 0xFC, 0x00, 0x00, 0x03, 0x00, 0x60, 0x01,
0x00, 0x00, 0x20, 0x00, 0x00, 0x00, 0x00, 0x00,
0x00, 0x10, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
0x00, 0x00, 0x10, 0x00, 0x00, 0x00, 0x00, 0x00,
https://learn.microsoft.com/en-us/windows/win32/debug/pe-format says
that a timestamp of zero can be used to represent a time that is not
"real or meaningful", so we do that.
As far as I can tell, the timestamp and checksum are only used in
DLLs, not directly executed .exe files.
Thanks to Freexian and the Debian LTS project for sponsoring this work.
BUG: https://bugzilla.samba.org/show_bug.cgi?id=13213
Signed-off-by: Douglas Bagnall <douglas.bagnall@catalyst.net.nz>
Reviewed-by: Andrew Bartlett <abartlet@samba.org>
We don't need to recreate the src array every time, and we don't need
to worry about Python 2 strings.
Signed-off-by: Douglas Bagnall <douglas.bagnall@catalyst.net.nz>
Reviewed-by: Andrew Bartlett <abartlet@samba.org>
Like many languages, Perl uses has randomisation to prevent nasty
users using crafted values that hash to the same number to effect a
denial of service. This means the traversal order of perl HASH tables
is different every time.
The IDL handed to pidl is trusted, so we don't really need
randomisation, but we do want to be sure the build is the same every
time.
I am not aware of hash randomisation causing problems, but it seems
prudent to avoid it.
We do a similar thing with PYTHONHASHSEED for the entire build.
Thanks to Freexian and the Debian LTS project for sponsoring this work.
BUG: https://bugzilla.samba.org/show_bug.cgi?id=13213
Signed-off-by: Douglas Bagnall <douglas.bagnall@catalyst.net.nz>
Reviewed-by: Andrew Bartlett <abartlet@samba.org>
Without the `$self->pidl("$fail");`, the exception is not raised.
We also try to improve the Python message.
Signed-off-by: Douglas Bagnall <douglas.bagnall@catalyst.net.nz>
Reviewed-by: Andrew Bartlett <abartlet@samba.org>
This function is only used by Python.pm, and was assuming any argument
unrecognised by hasType is a name. It sometimes isn't, resulting in
structures like this:
{
'DATA' => {
'TYPE' => 'STRUCT'
},
'NAME' => {
'TYPE' => 'STRUCT',
'ALIGN' => undef,
'SURROUNDING_ELEMENT' => undef,
'ORIGINAL' => {
'TYPE' => 'STRUCT',
'FILE' => 'source3/librpc/idl/smbXsrv.idl',
'LINE' => 101,
'NAME' => 'tevent_context'
},
'ELEMENTS' => undef,
'NAME' => 'tevent_context',
'PROPERTIES' => undef
},
'TYPE' => 'TYPEDEF'
};
The problem with that is we end up with the HASH reference as a name
in Python bindings, like this
PyErr_SetString(PyExc_TypeError, "Can not convert C Type struct HASH(0x5e2dfe5ee278) from Python");
which makes the build nondeterministic (as well as making the message
a little mysterious).
I think all the structures for which this happens are marked
'[ignore]' in IDL, meaning they are not transmitted on the wire. They
should perhaps also not have useless Python getsetters, but let's call
that a different problem.
Thanks to Freexian and the Debian LTS project for sponsoring this work.
BUG: https://bugzilla.samba.org/show_bug.cgi?id=13213
Signed-off-by: Douglas Bagnall <douglas.bagnall@catalyst.net.nz>
Reviewed-by: Andrew Bartlett <abartlet@samba.org>
These options are for packagers and vendors to set so that when
Samba developers are debugging an issue, we know exactly which
package is in use, and so have an idea if any patches have been
applied.
This is included in the string that a Samba backtrace gives,
as part of the PANIC message.
BUG: https://bugzilla.samba.org/show_bug.cgi?id=15654
REF: https://lists.samba.org/archive/samba-technical/2024-May/138992.html
Signed-off-by: Andrew Bartlett <abartlet@samba.org>
Reviewed-by: Douglas Bagnall <douglas.bagnall@catalyst.net.nz>
