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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
These are just as readable with `less` as they were with `zless`.
This file has been slightly manually edited to add line-breaks. There
is not an easy setting in Python's json module to get good formatting.
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): Mon Nov 27 02:10:12 UTC 2023 on atb-devel-224
This will make knownfails easier, given the names contain so many
regular expression metacharacters.
Signed-off-by: Douglas Bagnall <douglas.bagnall@catalyst.net.nz>
Reviewed-by: Andrew Bartlett <abartlet@samba.org>
These tests were named in the superclass, but were not actually run,
nor was the file in git.
Signed-off-by: Douglas Bagnall <douglas.bagnall@catalyst.net.nz>
Reviewed-by: Andrew Bartlett <abartlet@samba.org>
This makes it easy to separate a large number of examples into
successes and knownfails.
Signed-off-by: Douglas Bagnall <douglas.bagnall@catalyst.net.nz>
Reviewed-by: Andrew Bartlett <abartlet@samba.org>
We have two sets of tests: one that will succeed, and one that is going
to remain a knownfail. The latter involves Resource Attribute ACEs that
have the TX type, meaning "byte string".
In MS-DTYP, a bytestring is defined like "#6869210a", with a hash,
followed by an even number of hex digits. In other places on the web, it
is mentioned that zeroes in the string can be replaced by hashes, like so
"#686921#a". We discover via indirect fuzzing that a TX RA ACE can also
take bare integers, like "6869210a" or "2023". As it would be tricky to
support this, and there is no evidence of this occurring in the wild, we
will probably leave this as a knownfail.
Signed-off-by: Douglas Bagnall <douglas.bagnall@catalyst.net.nz>
Reviewed-by: Andrew Bartlett <abartlet@samba.org>
ACL revision 4 (SECURITY_ACL_REVISION_ADS) is effectively a superset
of revision 2 (SECURITY_ACL_REVISION_NT4), so any revision 2
ACL can be called revision 4 without any problem. But not vice versa:
a revision 4 ACL can contain ACE types that a revision 2 ACL can't. The
extra ACE types relate to objects.
Samba currently simplifies things by calling all its ACLs revision 4,
even if (as is commonly the case) the ACLs contain only revision 2 ACEs.
On the other hand, Windows will use revision 2 whenever it can. In other
tests we skip past this by forcing Windows ACLs to v4 before comparison.
This test is to remind us of the incompatibility.
It would not be hard to fix.
Signed-off-by: Douglas Bagnall <douglas.bagnall@catalyst.net.nz>
Reviewed-by: Andrew Bartlett <abartlet@samba.org>
If there are multiple identical ACEs in an SDDL ACL, Windows will decode
them all and put extra trailing zeroes at the end of the ACL.
In contrast, Samba will decode the ACEs and not put extra zeroes at the
end.
The problem comes when Samba tries to read a binary ACL from Windows that
has the extra zeroes, because Samba's ACL size calculation is based on
the size of its constituent ACEs, not the ACL size field.
There is no good reason for an ACL to have repeated ACEs, but they could
be added accidentally.
Signed-off-by: Douglas Bagnall <douglas.bagnall@catalyst.net.nz>
Reviewed-by: Andrew Bartlett <abartlet@samba.org>
This matters when we have a millions failures.
Signed-off-by: Douglas Bagnall <douglas.bagnall@catalyst.net.nz>
Reviewed-by: Andrew Bartlett <abartlet@samba.org>
Can Samba understand Windows security descriptors? Does it parse SDDL
the same way?
Here we test on over 7000 SDDL/descriptor pairs and find the answer
is pleasing. In later commits we will add more tests using different
classes of ACE.
The test cases are derived from fuzz seeds, exported to Windows via
the script in the last commit, with the Windows descriptor bytes found
using libcli/security/tests/windows/windows-sddl-test.py.
Signed-off-by: Douglas Bagnall <douglas.bagnall@catalyst.net.nz>
Reviewed-by: Andrew Bartlett <abartlet@samba.org>