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 definitions were the wrong way round.
Signed-off-by: Joseph Sutton <josephsutton@catalyst.net.nz>
Reviewed-by: Andrew Bartlett <abartlet@samba.org>
so that users of this header file don’t have to declare them.
Signed-off-by: Joseph Sutton <josephsutton@catalyst.net.nz>
Reviewed-by: Andrew Bartlett <abartlet@samba.org>
‘bool_value’ has the same type as ‘uint_value’. Removing the former
avoids our having more duplicate code than is strictly necessary.
Signed-off-by: Joseph Sutton <josephsutton@catalyst.net.nz>
Reviewed-by: Andrew Bartlett <abartlet@samba.org>
We can't add them via SDDL on Windows, and they aren't useful for
claims.
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): Wed Sep 27 00:41:26 UTC 2023 on atb-devel-224
You can't do things like '(a == b) == (c < d)'.
Signed-off-by: Douglas Bagnall <douglas.bagnall@catalyst.net.nz>
Reviewed-by: Andrew Bartlett <abartlet@samba.org>
The trouble is with expressions like "(!(()))", which boil down to a
single NOT operation with no argument, which is invalid and can't be
run or expressed as SDDL.
Signed-off-by: Douglas Bagnall <douglas.bagnall@catalyst.net.nz>
Reviewed-by: Andrew Bartlett <abartlet@samba.org>
A consequence of this is that we remove the confusing "length"
from the IDL, as it was the internal UTF8 length, not a wire
value. We use null terminated strings internally now.
Signed-off-by: Andrew Bartlett <abartlet@samba.org>
Reviewed-by: Douglas Bagnall <douglas.bagnall@catalyst.net.nz>
This was caught by the next condition, but this is clearer.
Signed-off-by: Andrew Bartlett <abartlet@samba.org>
Reviewed-by: Douglas Bagnall <douglas.bagnall@catalyst.net.nz>
These are like an object type if the callback (i.e. condtional ACE
conditions) succeeds, otherwise they are ignored.
Signed-off-by: Douglas Bagnall <douglas.bagnall@catalyst.net.nz>
Reviewed-by: Andrew Bartlett <abartlet@samba.org>
With the last caller of check_callback_ace_access() gone, so is that
function.
Signed-off-by: Douglas Bagnall <douglas.bagnall@catalyst.net.nz>
Reviewed-by: Andrew Bartlett <abartlet@samba.org>
To help clarify the logic, we make new functions that separate the
deny and allow cases, which helps keep track of what 'yes' and 'no'
mean and which incorporate the logic of token->evaluate_claims
handling, which determines when we want to run a conditional ACE, when
we want to ignore it, and when we want to take offence. In the case
when we decide to run it, we then need to decide whether to apply it
or ignore it based on the result. This last bit differs between allow
and deny aces, hence the two functions.
These functions will replace check_callback_ace_access() over the next
few commits.
In the case where token->evaluate_claims is
CLAIMS_EVALUATION_INVALID_STATE and the DACL contains a conditional
ACE, the maximum allowed is 0, as if it was a "deny everything" ACE.
This is an unexpected case. Most likely the evaluate_claims state
will be NEVER or ALWAYS. In the NEVER case the conditional ACE is
skipped, as would have happened in all cases before 4.20, while in the
ALWAYS case the conditional ACE is run and applied if successful.
Signed-off-by: Douglas Bagnall <douglas.bagnall@catalyst.net.nz>
Reviewed-by: Andrew Bartlett <abartlet@samba.org>
Most tests were prepared in advance, but we left these ones to test
the change.
Signed-off-by: Douglas Bagnall <douglas.bagnall@catalyst.net.nz>
Reviewed-by: Andrew Bartlett <abartlet@samba.org>
These will soon be used by python/samba/tests/sddl_conditional_ace.py,
and are a format understood by the Windows programs in
libcli/security/tests/windows.
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>
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>
