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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
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>
