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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
The tests that were in SddlWindowsFlagsAreDifferent have the behaviour
we want, and as we aim for Samba flags no longer being different, we
shift them to SddlNonCanonical. The tests in SddlSambaDoesItsOwnThing
are removed because they showed Samba's old behaviour around FA.
This will create knownfails, which will be fixed by the commit fixing the
value of "FA".
Signed-off-by: Andrew Bartlett <abartlet@samba.org>
Reviewed-by: Douglas Bagnall <douglas.bagnall@catalyst.net.nz>
Real ACEs don't have {} around their GUIDs. This will soon be banned.
Signed-off-by: Douglas Bagnall <douglas.bagnall@catalyst.net.nz>
Reviewed-by: Andrew Bartlett <abartlet@samba.org>
By normal GUID, I mean ones like f30e3bbf-9ff0-11d1-b603-0000f80367c1,
with four hyphens and no curly braces.
Signed-off-by: Douglas Bagnall <douglas.bagnall@catalyst.net.nz>
Reviewed-by: Andrew Bartlett <abartlet@samba.org>
It turns out that in accesss flags Windows will allow leading spaces
and spaces separating flags but not trailing spaces.
We choose to follow this in part because we found it happening in the
wild in our tests for upgradeprovision until a few commits ago.
Windows will also allow spaces in some parts of SIDs.
Signed-off-by: Douglas Bagnall <douglas.bagnall@catalyst.net.nz>
Reviewed-by: Andrew Bartlett <abartlet@samba.org>
sddl_decode_sid() will stop at the first non-SID character. Windows
doesn't allow white space here, and nor do we.
Signed-off-by: Douglas Bagnall <douglas.bagnall@catalyst.net.nz>
Reviewed-by: Andrew Bartlett <abartlet@samba.org>
Before we just ignored things like negative numbers, because they'd
end up being seen as not-numbers, so treated as flags, then as
not-flags.
Signed-off-by: Douglas Bagnall <douglas.bagnall@catalyst.net.nz>
Reviewed-by: Andrew Bartlett <abartlet@samba.org>
The short version is:
Running LOCAL-IDMAP-TDB-COMMON
test_getnewid1: PASSED!
test_setmap1: PASSED!
test_unixid2sid1: PASSED!
test_sid2unixid1: could not create uid map!
TEST LOCAL-IDMAP-TDB-COMMON FAILED!
LOCAL-IDMAP-TDB-COMMON took 0.029819 secs
Freed frame ../../source3/torture/torture.c:15748, expected ../../source3/torture/test_idmap_tdb_common.c:986.
===============================================================
INTERNAL ERROR: Frame not freed in order. in pid 3692106 (4.19.0pre1-DEVELOPERBUILD)
If you are running a recent Samba version, and if you think this problem is not yet fixed in the latest versions, please consider reporting this bug, see https://wiki.samba.org/index.php/Bug_Reporting
===============================================================
PANIC (pid 3692106): Frame not freed in order. in 4.19.0pre1-DEVELOPERBUILD
BACKTRACE: 11 stack frames:
#0 bin/shared/private/libgenrand-samba4.so(log_stack_trace+0x32) [0x7f2f39b430ba]
#1 bin/shared/private/libgenrand-samba4.so(smb_panic_log+0x1dd) [0x7f2f39b43037]
#2 bin/shared/private/libgenrand-samba4.so(smb_panic+0x1c) [0x7f2f39b43056]
#3 bin/shared/libsamba-util.so.0(+0x75309) [0x7f2f3a659309]
#4 bin/shared/private/libtalloc-samba4.so(+0x5cc6) [0x7f2f3a758cc6]
#5 bin/shared/private/libtalloc-samba4.so(+0x6173) [0x7f2f3a759173]
#6 bin/shared/private/libtalloc-samba4.so(_talloc_free+0x10c) [0x7f2f3a75a54b]
#7 /data/samba/samba-review/bin/smbtorture3(main+0xa97) [0x55cb3dc8cedc]
#8 /lib/x86_64-linux-gnu/libc.so.6(+0x29d90) [0x7f2f396d4d90]
#9 /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0x80) [0x7f2f396d4e40]
#10 /data/samba/samba-review/bin/smbtorture3(_start+0x25) [0x55cb3dc59895]
smb_panic(): calling panic action [/data/samba/samba-review/selftest/gdb_backtrace 3692106]
Signed-off-by: Douglas Bagnall <douglas.bagnall@catalyst.net.nz>
Reviewed-by: Andrew Bartlett <abartlet@samba.org>
Windows converts hex numbers into flags differently, and has different
ideas of what constitutes "FA", and possibly others.
Signed-off-by: Douglas Bagnall <douglas.bagnall@catalyst.net.nz>
Reviewed-by: Andrew Bartlett <abartlet@samba.org>
The C version tests the public SDDL API on Windows which seems to follow
Active Directory closely, though case in hex numbers is reversed vis-a-vis
defaultSecurityDescriptor.
The python version is less refined and tests powershell functions.
Signed-off-by: Douglas Bagnall <douglas.bagnall@catalyst.net.nz>
Reviewed-by: Andrew Bartlett <abartlet@samba.org>
These ones we might want to match. They are understandable behaviours,
like matching lowercase flags and coping with whitespace in some
places. These tests are set up to document the differences without
overwhelming the knownfails.
Signed-off-by: Douglas Bagnall <douglas.bagnall@catalyst.net.nz>
Reviewed-by: Andrew Bartlett <abartlet@samba.org>
If the subclass has `should_succeed = False`, all the cases
in that class will be tested to ensure they can't be
successfully parsed.
Signed-off-by: Douglas Bagnall <douglas.bagnall@catalyst.net.nz>
Reviewed-by: Andrew Bartlett <abartlet@samba.org>
This of course allows for fine-grained knownfails.
Signed-off-by: Douglas Bagnall <douglas.bagnall@catalyst.net.nz>
Reviewed-by: Andrew Bartlett <abartlet@samba.org>
Adding, diversifying, and disambiguating. The leading portion of the
test stirngs will soon be used in the test name, and strings that
don't differ in the first hundred characters will cause naming
clashes. There is no good reason for them all to test the same flags
in the same order.
Signed-off-by: Douglas Bagnall <douglas.bagnall@catalyst.net.nz>
Reviewed-by: Andrew Bartlett <abartlet@samba.org>
The examples in the canonical list are already in the form that
Windows and Samba will use for that SD. We check the round trip.
The examples in the non-canonical list will change in a round trip, so
we also give the string we think they should end up as. These have
been checked on Windows.
Signed-off-by: Douglas Bagnall <douglas.bagnall@catalyst.net.nz>
Reviewed-by: Andrew Bartlett <abartlet@samba.org>
The test will fail right now because it makes round trip assertions.
Signed-off-by: Douglas Bagnall <douglas.bagnall@catalyst.net.nz>
Reviewed-by: Andrew Bartlett <abartlet@samba.org>
It's not that I think our SD equality check will miss anything, but we
are here to test things like that.
Signed-off-by: Douglas Bagnall <douglas.bagnall@catalyst.net.nz>
Reviewed-by: Andrew Bartlett <abartlet@samba.org>
I think it worked, but the convention is that tests have a test_ prefix,
and it woudn't be surpoising if something somewhere decides to depend on
that.
Signed-off-by: Douglas Bagnall <douglas.bagnall@catalyst.net.nz>
Reviewed-by: Andrew Bartlett <abartlet@samba.org>
It is now easier to see where one SD ends and another starts.
Best looked at with -b or --word-diff.
Signed-off-by: Douglas Bagnall <douglas.bagnall@catalyst.net.nz>
Reviewed-by: Andrew Bartlett <abartlet@samba.org>
This is because in ceetain places we compare strings rather than security
descriptors.
Signed-off-by: Douglas Bagnall <douglas.bagnall@catalyst.net.nz>
Reviewed-by: Andrew Bartlett <abartlet@samba.org>
We don't see this happening on Windows.
Signed-off-by: Douglas Bagnall <douglas.bagnall@catalyst.net.nz>
Reviewed-by: Andrew Bartlett <abartlet@samba.org>
Our previous behaviour (at least with glibc) was to clip off the extra
bits, so that 0x123456789 would become 0x23456789. That's kind of the
obvious thing, but is not what Windows does, which is to saturate the
value, rounding to 0xffffffff. The effect of this is to turn on all
the flags, which quite possibly not what you meant.
Now we just return an error.
Signed-off-by: Douglas Bagnall <douglas.bagnall@catalyst.net.nz>
Reviewed-by: Andrew Bartlett <abartlet@samba.org>
The string "S:D:P" is parsed by us and Windows into a valid struct,
which has an empty DACL with the PROTECTED flag, and an empty SACL.
This is reconstructed in canonical order as "D:PS:", which Windows
will correctly parse, but Samba has assumed the "S" is a bad DACL
flag. Now we don't make that assumption.
Signed-off-by: Douglas Bagnall <douglas.bagnall@catalyst.net.nz>
Reviewed-by: Andrew Bartlett <abartlet@samba.org>
These occur canonically when the indentifier authority is > 2^32, but
also are accepted by Windows for any number.
There is a tricky case with an "O:" or "G:" SID that is immediately
followed by a "D:" dacl, because the "D" looks like a hex digit. When
we detect this we need to subtract one from the length.
We also need to do look out for trailing garbage. This was not an
issue before because any string caught by the strspn(...,
"-0123456789") would be either rejected or fully comsumed by
dom_sid_parse_talloc(), but with hex digits, a string like
"S-1-1-2x0xabcxxx-X" would be successfully parsed as "S-1-1-2", and
the "x0xabcxxx-X" would be skipped over. That's why we switch to using
dom_sid_parse_endp(), so we can compare the consumed length to the
expected length.
Signed-off-by: Douglas Bagnall <douglas.bagnall@catalyst.net.nz>
Reviewed-by: Andrew Bartlett <abartlet@samba.org>
previously a string could have anything in it, so long as every second
character was ':'.
Signed-off-by: Douglas Bagnall <douglas.bagnall@catalyst.net.nz>
Reviewed-by: Andrew Bartlett <abartlet@samba.org>
The man page notes:
The standards require that the argument c for these functions
is either EOF or a value that is representable in the type
unsigned char. If the argument c is of type char, it must be
cast to unsigned char, as in the following example:
Signed-off-by: Douglas Bagnall <douglas.bagnall@catalyst.net.nz>
Reviewed-by: Andrew Bartlett <abartlet@samba.org>
Following Windows, the numbers that would be octal (e.g. "0123") are
converted to decimal by skipping over the zeros.
Signed-off-by: Douglas Bagnall <douglas.bagnall@catalyst.net.nz>
Reviewed-by: Andrew Bartlett <abartlet@samba.org>
We don't want octal numbers or overflows.
Signed-off-by: Douglas Bagnall <douglas.bagnall@catalyst.net.nz>
Reviewed-by: Andrew Bartlett <abartlet@samba.org>
The second one came with code obsoleting the "BIG NOTE" about 10 years
ago, but that code later wandered off somewhere else.
Signed-off-by: Douglas Bagnall <douglas.bagnall@catalyst.net.nz>
Reviewed-by: Andrew Bartlett <abartlet@samba.org>
No.
That's good and expected because a failure here should fall back to the
next thing in the simple bind pecking order (canonical names).
Signed-off-by: Douglas Bagnall <douglas.bagnall@catalyst.net.nz>
Reviewed-by: Andrew Bartlett <abartlet@samba.org>
