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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
Existing callers will pass an empty string, later a new caller will pass an
explicit DC name taken from the wbinfo command line.
Signed-off-by: Ralph Boehme <slow@samba.org>
Reviewed-by: Jeremy Allison <jra@samba.org>
This basically moves the functionality to connect the socket to the currently
preferred DC to a new helper function connect_preferred_dc() that is called from
the renamed function find_new_dc().
find_dc() now either returns a connected to the preferred DC or a new DC until
all possible DCs are exhausted and cm_open_connection() can just call find_dc()
to get a connected socket and pass it to cm_prepare_connection().
While at it reorder the args of find_dc() and make the only real out arg "fd"
the last one.
Signed-off-by: Ralph Boehme <slow@samba.org>
Reviewed-by: Jeremy Allison <jra@samba.org>
Simplify to retry logic: if cm_prepare_connection() succeeded just exit the
retry loop, only if it failed check the "retry" variable.
Signed-off-by: Ralph Boehme <slow@samba.org>
Reviewed-by: Jeremy Allison <jra@samba.org>
Remove the dcname and pss args from find_new_dc(). The caller passes in the
domain anyway, so let's fill in domain->dcname and domain->dcaddr directly.
Signed-off-by: Ralph Boehme <slow@samba.org>
Reviewed-by: Jeremy Allison <jra@samba.org>
Making these variables hidden prevents the parent
class gp_chromium_ext from reading them when
subclassed in gp_chrome_ext. This caused the
chrome policies to be installed in the chromium
directories.
Signed-off-by: David Mulder <dmulder@samba.org>
Reviewed-by: Jeremy Allison <jra@samba.org>
Autobuild-User(master): Jeremy Allison <jra@samba.org>
Autobuild-Date(master): Wed Dec 21 03:05:46 UTC 2022 on sn-devel-184
A bug cropped up in the rsop that was causing a
crash because this wasn't being tested.
Signed-off-by: David Mulder <dmulder@samba.org>
Reviewed-by: Jeremy Allison <jra@samba.org>
The output must be a string value, or it will
crash. Chromium policies output integers, which
was causing the parser to crash.
Signed-off-by: David Mulder <dmulder@samba.org>
Reviewed-by: Jeremy Allison <jra@samba.org>
This test exercises the gp_file_applier and
ensures that when a policy is modified, no old
policy is left behind.
Signed-off-by: David Mulder <dmulder@samba.org>
Reviewed-by: Jeremy Allison <jra@samba.org>
Currently applied files which are manually
removed do not get re-applied.
Signed-off-by: David Mulder <dmulder@samba.org>
Reviewed-by: Jeremy Allison <jra@samba.org>
This is currently a significant drawback of Samba
Group Policy. CSEs MUST be aware of policy changes
such as modification, removal, etc. This is a
complex process, and is easy to mess up. Here I
add 'appliers' (the first being for files), which
handle the complexty transparently to ensure this
is done correctly.
Signed-off-by: David Mulder <dmulder@samba.org>
Reviewed-by: Jeremy Allison <jra@samba.org>
iServiceIndex may indicate an empty slot in the ServicePtrs
array. In this case, lpcfg_serivce_ok(ServicePtrs[iServiceIndex])
may trigger a NULL deref and crash. Skipping the check
here will cause a scan of the array in add_a_service() and the
NULL slot will be used safely.
BUG: https://bugzilla.samba.org/show_bug.cgi?id=15267
Signed-off-by: Andrew Walker <awalker@ixsystems.com>
Reviewed-by: Jeremy Allison <jra@samba.org>
Autobuild-User(master): Jeremy Allison <jra@samba.org>
Autobuild-Date(master): Tue Dec 20 18:49:54 UTC 2022 on sn-devel-184
==17828==ERROR: AddressSanitizer: stack-use-after-scope on address 0x7ffc37790230 at pc 0x7fc37e2a3a11 bp 0x7ffc3778fec0 sp 0x7ffc3778feb8
READ of size 16 at 0x7ffc37790230 thread T0
#0 0x7fc37e2a3a10 in ndr_push_spoolss_GetPrinter librpc/gen_ndr/ndr_spoolss.c:27123
#1 0x7fc380629b30 in dcerpc_binding_handle_call_send ../../librpc/rpc/binding_handle.c:416
#2 0x7fc38062a132 in dcerpc_binding_handle_call ../../librpc/rpc/binding_handle.c:553
#3 0x7fc37ed113c9 in dcerpc_spoolss_GetPrinter_r librpc/gen_ndr/ndr_spoolss_c.c:1947
#4 0x5570ba6c4d03 in test_devicemode_full ../../source4/torture/rpc/spoolss.c:2249
#5 0x5570ba6e61ea in test_PrinterInfo_DevModes ../../source4/torture/rpc/spoolss.c:2384
#6 0x5570ba6e61ea in test_PrinterInfo_DevMode ../../source4/torture/rpc/spoolss.c:2488
#7 0x5570ba6e61ea in test_printer_dm ../../source4/torture/rpc/spoolss.c:9082
#8 0x7fc37fc7b67d in wrap_test_with_simple_test ../../lib/torture/torture.c:808
#9 0x7fc37fc7d40b in internal_torture_run_test ../../lib/torture/torture.c:516
#10 0x7fc37fc7d87c in torture_run_tcase_restricted ../../lib/torture/torture.c:581
#11 0x7fc37fc7deb2 in torture_run_suite_restricted ../../lib/torture/torture.c:435
#12 0x5570ba89a65d in run_matching ../../source4/torture/smbtorture.c:95
#13 0x5570ba89a6e4 in run_matching ../../source4/torture/smbtorture.c:105
#14 0x5570ba89a6e4 in run_matching ../../source4/torture/smbtorture.c:105
#15 0x5570ba89b3e4 in torture_run_named_tests ../../source4/torture/smbtorture.c:172
#16 0x5570ba89f3e0 in main ../../source4/torture/smbtorture.c:750
#17 0x7fc37c62c5af in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58
#18 0x7fc37c62c678 in __libc_start_main_impl ../csu/libc-start.c:381
#19 0x5570ba49e824 in _start ../sysdeps/x86_64/start.S:115
Address 0x7ffc37790230 is located in stack of thread T0 at offset 160 in frame
#0 0x5570ba6c4562 in test_devicemode_full ../../source4/torture/rpc/spoolss.c:2186
Signed-off-by: Andreas Schneider <asn@samba.org>
Reviewed-by: Jeremy Allison <jra@samba.org>
Autobuild-User(master): Jeremy Allison <jra@samba.org>
Autobuild-Date(master): Tue Dec 20 06:55:45 UTC 2022 on sn-devel-184
==12122==ERROR: AddressSanitizer: stack-use-after-scope on address 0x7fff494dd900 at pc 0x7fdaebea71e3 bp 0x7fff494dd430 sp 0x7fff494dd428
READ of size 4 at 0x7fff494dd900 thread T0
#0 0x7fdaebea71e2 in ndr_push_spoolss_SetPrinterInfo8 librpc/gen_ndr/ndr_spoolss.c:8618
#1 0x7fdaebea71e2 in ndr_push_spoolss_SetPrinterInfo librpc/gen_ndr/ndr_spoolss.c:8796
#2 0x7fdaebea7482 in ndr_push_spoolss_SetPrinterInfoCtr librpc/gen_ndr/ndr_spoolss.c:9163
#3 0x7fdaebea7580 in ndr_push_spoolss_SetPrinter librpc/gen_ndr/ndr_spoolss.c:27000
#4 0x7fdaee3e1b30 in dcerpc_binding_handle_call_send ../../librpc/rpc/binding_handle.c:416
#5 0x7fdaee3e2132 in dcerpc_binding_handle_call ../../librpc/rpc/binding_handle.c:553
#6 0x7fdaecb103fd in dcerpc_spoolss_SetPrinter_r librpc/gen_ndr/ndr_spoolss_c.c:1722
#7 0x559a7294c2f1 in test_SetPrinter ../../source4/torture/rpc/spoolss.c:1293
#8 0x559a7297b4d4 in test_devmode_set_level ../../source4/torture/rpc/spoolss.c:2126
#9 0x559a7299cfa1 in test_PrinterInfo_DevModes ../../source4/torture/rpc/spoolss.c:2344
#10 0x559a7299cfa1 in test_PrinterInfo_DevMode ../../source4/torture/rpc/spoolss.c:2489
#11 0x559a7299cfa1 in test_printer_dm ../../source4/torture/rpc/spoolss.c:9083
#12 0x7fdaeda9867d in wrap_test_with_simple_test ../../lib/torture/torture.c:808
#13 0x7fdaeda9a40b in internal_torture_run_test ../../lib/torture/torture.c:516
#14 0x7fdaeda9a87c in torture_run_tcase_restricted ../../lib/torture/torture.c:581
#15 0x7fdaeda9aeb2 in torture_run_suite_restricted ../../lib/torture/torture.c:435
#16 0x559a72b51668 in run_matching ../../source4/torture/smbtorture.c:95
#17 0x559a72b516ef in run_matching ../../source4/torture/smbtorture.c:105
#18 0x559a72b516ef in run_matching ../../source4/torture/smbtorture.c:105
#19 0x559a72b523ef in torture_run_named_tests ../../source4/torture/smbtorture.c:172
#20 0x559a72b563eb in main ../../source4/torture/smbtorture.c:750
#21 0x7fdaea42c5af in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58
#22 0x7fdaea42c678 in __libc_start_main_impl ../csu/libc-start.c:381
#23 0x559a72755824 in _start ../sysdeps/x86_64/start.S:115
Address 0x7fff494dd900 is located in stack of thread T0 at offset 32 in frame
#0 0x559a7297b111 in test_devmode_set_level ../../source4/torture/rpc/spoolss.c:2090
Signed-off-by: Andreas Schneider <asn@samba.org>
Reviewed-by: Jeremy Allison <jra@samba.org>
Signed-off-by: Ralph Boehme <slow@samba.org>
Reviewed-by: Jeremy Allison <jra@samba.org>
Autobuild-User(master): Jeremy Allison <jra@samba.org>
Autobuild-Date(master): Tue Dec 20 01:32:07 UTC 2022 on sn-devel-184
We shouldn't get a node with a zero code, and there's probably nothing
to do but stop.
CID 1517261 (#1-2 of 2): Bad bit shift operation
(BAD_SHIFT)11. negative_shift: In expression j >> offset - k,
shifting by a negative amount has undefined behavior. The shift
amount, offset - k, is -3.
Signed-off-by: Douglas Bagnall <douglas.bagnall@catalyst.net.nz>
Reviewed-by: Jeremy Allison <jra@samba.org>
Autobuild-User(master): Jeremy Allison <jra@samba.org>
Autobuild-Date(master): Mon Dec 19 23:29:04 UTC 2022 on sn-devel-184
Because we just wrote the intermediate representation to have no zero
distances, we can be sure it doesn't, but Coverity doesn't know. If
distance is zero, `bitlen_nonzero_16(distance)` would be bad.
CID 1517278 (#1 of 1): Bad bit shift operation
(BAD_SHIFT)41. large_shift: In expression 1 << code_dist, left
shifting by more than 31 bits has undefined behavior. The shift
amount, code_dist, is 65535.
Signed-off-by: Douglas Bagnall <douglas.bagnall@catalyst.net.nz>
Reviewed-by: Jeremy Allison <jra@samba.org>
Very long matches would be written instead as very very long matches.
We can't in fact hit this because we have a MAX_MATCH_LENGTH defined
as 64M, but if we could, it might make certain 2GB+ strings impossible
to compress.
CID 1517275 (#1 of 1): Unintended sign extension
(SIGN_EXTENSION)sign_extension: Suspicious implicit sign extension:
intermediate[i + 2UL] with type uint16_t (16 bits, unsigned) is
promoted in intermediate[i + 2UL] << 16 to type int (32 bits, signed),
then sign-extended to type unsigned long (64 bits, unsigned). If
intermediate[i + 2UL] << 16 is greater than 0x7FFFFFFF, the upper bits
of the result will all be 1.
Signed-off-by: Douglas Bagnall <douglas.bagnall@catalyst.net.nz>
Reviewed-by: Jeremy Allison <jra@samba.org>
None of our test vectors are 18446744073709551615 bytes long, which
means we can know an `expected_length == returned_length` check will
catch the case where the compression function returns -1 for error. We
know that, but Coverity doesn't.
It's the same thing over and over again, in two different patterns:
>>> CID 1517301: Memory - corruptions (OVERRUN)
>>> Calling "memcmp" with "original.data" and "original.length" is
suspicious because of the very large index, 18446744073709551615. The index
may be due to a negative parameter being interpreted as unsigned.
393 if (original.length != decomp_written ||
394 memcmp(decompressed.data,
395 original.data,
396 original.length) != 0) {
397 debug_message("\033[1;31mgot %zd, expected %zu\033[0m\n",
398 decomp_written,
*** CID 1517299: Memory - corruptions (OVERRUN)
/lib/compression/tests/test_lzxpress_plain.c: 296 in
test_lzxpress_plain_decompress_more_compressed_files()
290 debug_start_timer();
291 written = lzxpress_decompress(p.compressed.data,
292 p.compressed.length,
293 dest,
294 p.decompressed.length);
295 debug_end_timer("decompress", p.decompressed.length);
>>> CID 1517299: Memory - corruptions (OVERRUN)
>>> Calling "memcmp" with "p.decompressed.data" and
"p.decompressed.length" is suspicious because of the very large index,
18446744073709551615. The index may be due to a negative parameter being
interpreted as unsigned.
296 if (written == p.decompressed.length &&
297 memcmp(dest, p.decompressed.data, p.decompressed.length)
== 0) {
298 debug_message("\033[1;32mdecompressed %s!
Signed-off-by: Douglas Bagnall <douglas.bagnall@catalyst.net.nz>
Reviewed-by: Jeremy Allison <jra@samba.org>
We know that code is non-zero, because it comes from the combination of
the intermediate representation and the symbol tables that were generated
at the same time. But Coverity doesn't know that, and it thinks we could
be doing undefined things in the subsequent shift.
CID 1517302: Integer handling issues (BAD_SHIFT)
In expression "1 << code_bit_len", shifting by a negative amount has
Signed-off-by: Douglas Bagnall <douglas.bagnall@catalyst.net.nz>
Reviewed-by: Jeremy Allison <jra@samba.org>
The struct write_context bit_len attribute is always between 0 and 31,
but if the next patches are applied without this, SUSE GCC -O3 will
worry thusly:
../../lib/compression/lzxpress_huffman.c: In function
‘lzxpress_huffman_compress’:
../../lib/compression/lzxpress_huffman.c:953:5: error: assuming signed
overflow does not occur when simplifying conditional to constant
[-Werror=strict-overflow]
if (wc->bit_len > 16) {
^
cc1: all warnings being treated as errors
Inspection tell us that the invariant holds. Nevertheless, we can
safely use an unsigned type and insist that over- or under- flow is
bad.
Signed-off-by: Douglas Bagnall <douglas.bagnall@catalyst.net.nz>
Reviewed-by: Jeremy Allison <jra@samba.org>
The 'compressed' string can be about 9/8 the size of the decompressed
string, but we didn't allow enough memory in the fuzz target for that.
Then when it failed, we didn't check.
Credit to OSSFuzz.
Signed-off-by: Douglas Bagnall <douglas.bagnall@catalyst.net.nz>
Reviewed-by: Jeremy Allison <jra@samba.org>
We had
output[output_pos - distance];
where output_pos and distance are size_t and distance can be greater
than output_pos (because it refers to a place in the previous block).
The underflow is defined, leading to a big number, and when
sizeof(size_t) == sizeof(*uint8_t) the subsequent overflow works as
expected. But if size_t is smaller than a pointer, bad things will
happen.
This was found by OSSFuzz with
'UBSAN_OPTIONS=print_stacktrace=1:silence_unsigned_overflow=1'.
Credit to OSSFuzz.
Signed-off-by: Douglas Bagnall <douglas.bagnall@catalyst.net.nz>
Reviewed-by: Volker Lendecke <vl@samba.org>
Reviewed-by: Jeremy Allison <jra@samba.org>
share_info.tdb has permissions of 0o600 and so we need
to become_root() prior to retrieving the security info.
BUG: https://bugzilla.samba.org/show_bug.cgi?id=15265
Signed-off-by: Andrew Walker <awalker@ixsystems.com>
Reviewed-by: Jeremy Allison <jra@samba.org>
Autobuild-User(master): Jeremy Allison <jra@samba.org>
Autobuild-Date(master): Mon Dec 19 20:41:15 UTC 2022 on sn-devel-184
It's good to have a consistent set of hash_size/flags for all aspects of
an open file handle. Currently we're using 4 databases:
smbXsrv_open_global.tdb, leases.tdb, locking.tdb and brlock.tdb.
While at it also crank up the hashsize if the smbXsrv_tcon and smbXsrv_session
TDBs. The default TDB hash size is insanely small and disk space is cheap these
days, by going with the much larger hash size we get O(1) lookup instead of O(n)
for moderate to large loads with a few thousand objects.
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): Mon Dec 19 16:40:15 UTC 2022 on sn-devel-184
Guenther
Signed-off-by: Guenther Deschner <gd@samba.org>
Reviewed-by: Jeremy Allison <jra@samba.org>
Autobuild-User(master): Jeremy Allison <jra@samba.org>
Autobuild-Date(master): Fri Dec 16 21:35:45 UTC 2022 on sn-devel-184
Nobody looks at the out params anymore
Signed-off-by: Volker Lendecke <vl@samba.org>
Reviewed-by: Jeremy Allison <jra@samba.org>
Autobuild-User(master): Volker Lendecke <vl@samba.org>
Autobuild-Date(master): Fri Dec 16 08:42:18 UTC 2022 on sn-devel-184
Now that fname is writable, we can avoid a bit of complexity with
clistr_smb2_extract_snapshot_token()
Signed-off-by: Volker Lendecke <vl@samba.org>
Signed-off-by: Jeremy Allison <jra@samba.org>
Allows us to pass in path separator from a new function without
changing existing calling code.
Signed-off-by: Jeremy Allison <jra@samba.org>
Reviewed-by: Volker Lendecke <vl@samba.org>
