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 implicit right of an object's owner to modify its security
descriptor no longer exists, according to the new access rules. However,
we continue to grant this implicit right for fileserver access checks.
BUG: https://bugzilla.samba.org/show_bug.cgi?id=14810
Signed-off-by: Nadezhda Ivanova <nivanova@symas.com>
Reviewed-by: Andrew Bartlett <abartlet@samba.org>
Signed-off-by: Joseph Sutton <josephsutton@catalyst.net.nz>
Reviewed-by: Andrew Bartlett <abartlet@samba.org>
Reviewed-by: Andreas Schneider <asn@samba.org>
Deny ACEs must always be evaluated against explicitly granted rights
from previous ACEs.
BUG: https://bugzilla.samba.org/show_bug.cgi?id=13812
Signed-off-by: Ralph Boehme <slow@samba.org>
Reviewed-by: Jeremy Allison <jra@samba.org>
We basically must process the Owner Rights ACEs as any other ACE wrt to the
order of adding granted permissions and checking denied permissions. According
to MS-DTYP 2.5.3.2 Owner Rights ACEs must be evaluated in the main loop over
the ACEs in an ACL and the corresponding access_mask must be directly applied
to bits_remaining. We currently defer this to after the loop over the ACEs in
ACL, this is wrong.
We just have to do some initial magic to determine if an ACL contains and
Owner Rights ACEs, and in case it doesn't we grant SEC_STD_WRITE_DAC |
SEC_STD_READ_CONTROL at the *beginning*. MS-DTYP:
-- the owner of an object is always granted READ_CONTROL and WRITE_DAC.
CALL SidInToken(Token, SecurityDescriptor.Owner, PrincipalSelfSubst)
IF SidInToken returns True THEN
IF DACL does not contain ACEs from object owner THEN
Remove READ_CONTROL and WRITE_DAC from RemainingAccess
Set GrantedAccess to GrantedAccess or READ_CONTROL or WRITE_OWNER
END IF
END IF
BUG: https://bugzilla.samba.org/show_bug.cgi?id=13812
Signed-off-by: Ralph Boehme <slow@samba.org>
Reviewed-by: Jeremy Allison <jra@samba.org>
This was missing in 44590c1b70.
Bug: https://bugzilla.samba.org/show_bug.cgi?id=13812
Signed-off-by: Ralph Boehme <slow@samba.org>
Reviewed-by: David Disseldorp <ddiss@samba.org>
Autobuild-User(master): David Disseldorp <ddiss@samba.org>
Autobuild-Date(master): Thu Feb 28 19:18:16 UTC 2019 on sn-devel-144
An 'Object Access Allowed' ACE that assigned 'Control Access' (CR)
rights to a specific attribute would not actually grant access.
What was happening was the remaining_access mask for the object_tree
nodes would be Read Property (RP) + Control Access (CR). The ACE mapped
to the schemaIDGUID for a given attribute, which would end up being a
child node in the tree. So the CR bit was cleared for a child node, but
not the rest of the tree. We would then check the user had the RP access
right, which it did. However, the RP right was cleared for another node
in the tree, which still had the CR bit set in its remaining_access
bitmap, so Samba would not grant access.
Generally, the remaining_access only ever has one bit set, which means
this isn't a problem normally. However, in the Control Access case there
are 2 separate bits being checked, i.e. RP + CR.
One option to fix this problem would be to clear the remaining_access
for the tree instead of just the node. However, the Windows spec is
actually pretty clear on this: if the ACE has a CR right present, then
you can stop any further access checks.
BUG: https://bugzilla.samba.org/show_bug.cgi?id=13434
Signed-off-by: Tim Beale <timbeale@catalyst.net.nz>
Reviewed-by: Andrew Bartlett <abartlet@samba.org>
Reviewed-by: Gary Lockyer <gary@catalyst.net.nz>
Reading the spec and then reading the code makes sense, but we could
comment the code more so it makes sense on its own.
BUG: https://bugzilla.samba.org/show_bug.cgi?id=13434
Signed-off-by: Tim Beale <timbeale@catalyst.net.nz>
Reviewed-by: Andrew Bartlett <abartlet@samba.org>
Reviewed-by: Gary Lockyer <gary@catalyst.net.nz>
Object-specific access checks refer to a specific section of the
MS-ADTS, and the code closely matches the spec. We need to extend this
logic to properly handle the Control-Access Right (CR), so it makes
sense to split the logic out into its own function.
This patch just moves the code, and should not alter the logic (apart
from ading in the boolean grant_access return variable.
BUG: https://bugzilla.samba.org/show_bug.cgi?id=13434
Signed-off-by: Tim Beale <timbeale@catalyst.net.nz>
Reviewed-by: Andrew Bartlett <abartlet@samba.org>
Reviewed-by: Gary Lockyer <gary@catalyst.net.nz>
Reported and proposed fix by Shilpa K <shilpa.krishnareddy@gmail.com>.
When processing DENY ACE entries for owner rights SIDs (S-1-3-4) the
code OR's in the deny access mask bits without taking into account if
they were being requested in the requested access mask.
E.g. The current logic has:
An ACL containining:
[0] SID: S-1-3-4
TYPE: DENY
MASK: WRITE_DATA
[1] SID: S-1-3-4
TYPE: ALLOW
MASK: ALLOW_ALL
prohibits an open request by the owner for READ_DATA - even though this
is explicitly allowed.
Furthermore a non-canonical ACL containing:
[0] SID: User SID 1-5-21-something
TYPE: ALLOW
MASK: READ_DATA
[1] SID: S-1-3-4
TYPE: DENY
MASK: READ_DATA
[2] SID: User SID 1-5-21-something
TYPE: ALLOW
MASK: WRITE_DATA
prohibits an open request by the owner for READ_DATA|WRITE_DATA - even
though READ_DATA is explicitly allowed in ACE no 0 and is thus already
filtered out of the "access-still-needed" mask when the deny ACE no 1 is
evaluated.
BUG: https://bugzilla.samba.org/show_bug.cgi?id=12466
Signed-off-by: Jeremy Allison <jra@samba.org>
Signed-off-by: Ralph Boehme <slow@samba.org>
Reviewed-by: Ralph Boehme <slow@samba.org>
Restore and backup privileges are not relevant to ldap
access checks, and the TakeOwnership privilege should
grant write_owner right
Signed-off-by: Nadezhda Ivanova <nivanova@symas.com>
Reviewed-by: Andrew Bartlett <abartlet@samba.org>
Signed-off-by: Richard Sharpe <rsharpe@samba.org>
Reviewed-by: Jeremy Allison <jra@samba.org>
Autobuild-User(master): Jeremy Allison <jra@samba.org>
Autobuild-Date(master): Sat Feb 23 19:28:15 CET 2013 on sn-devel-104
The inherited_type is only used to decide if aces should be inherited
effectively or not (INHERIT_ONLY) for the specified object.
Signed-off-by: Stefan Metzmacher <metze@samba.org>
Reviewed-by: Matthieu Patou <mat@matws.net>
Signed-off-by: Jeremy Allison <jra@samba.org>
Autobuild-User: Jeremy Allison <jra@samba.org>
Autobuild-Date: Wed Mar 14 02:26:34 CET 2012 on sn-devel-104
Signed-off-by: Jeremy Allison <jra@samba.org>
Autobuild-User: Jeremy Allison <jra@samba.org>
Autobuild-Date: Sat Mar 10 01:33:45 CET 2012 on sn-devel-104
Ensure we process the entire ACE list instead of returning ACCESS_DENIED
and terminating the walk - ensure we only return the exact bits that cause
the access to be denied. Some of the S3 fileserver needs to know if we
are only denied DELETE access before overriding it by looking at the
containing directory ACL.
Autobuild-User: Jeremy Allison <jra@samba.org>
Autobuild-Date: Wed Jan 11 19:24:53 CET 2012 on sn-devel-104
In the file server SEC_STD_DELETE is granted on the file/directory
or by FILE_DELETE_CHILD on the parent directory.
metze
Autobuild-User: Stefan Metzmacher <metze@samba.org>
Autobuild-Date: Mon Mar 21 23:25:05 CET 2011 on sn-devel-104
Jeremy, you put a #if 0 around this logic in this commit:
8344e945 (Jeremy Allison 2008-10-31 10:51:45 -0700 181)
is this still needed?
Pair-Programmed-With: Andrew Bartlett <abartlet@samba.org>
Autobuild-User: Andrew Tridgell <tridge@samba.org>
Autobuild-Date: Thu Oct 14 03:16:41 UTC 2010 on sn-devel-104