Hi Jean-Pierre,
much thanks for the valuable links.
So I now understand:
1.) Windows security management relies on the canonical order of the ACEs. The tools are not
designed to configure the order as a choice of the user, even from the C APIs, so the resulting ACL
should always fulfill the canonicl order.
Quoting from:
https://msdn.microsoft.com/en-us/library/windows/desktop/aa379576%28v=vs.85%29.aspx
/"The //*SetEntriesInAcl*//function places any new access-denied ACEs at the
beginning of the
list of ACEs for the new //*ACL*
<https://msdn.microsoft.com/en-us/library/windows/desktop/aa374931%28v=vs.85%29.aspx>//.
This
function places any new access-allowed ACEs just before any existing
access-allowed ACEs.//"
/
2.) Windows AccessCheck depends on the order of the ACEs. If the order is not canonical, it
calculates the permissions in a way, which emulates POSIX modes, which are not officially provided
by Windows, but as a side effect solve the needs of mapping those mode combinations with NTFS-3G.
3.) The canonical order rule only says, that any ACCESS_DENY type ACEs should precede any
ACCESS_ALLOW type ACEs. There is no rule about the order upon their SIDs.
4.) As far as I can see, Windows AccessCheck is independent from the ACE order
upon their SIDs.
5.) In build_ownadmin_permissions() of acls.c the logic around the "firstapply"-flag doesn't
distinguish the order of ACE types, but of their SIDs. So this has nothing to do with the cases
described in your links.
==> So I suggest to remove the logic around the "firstapply"-flag for a test
run, see attached patch.
Would you please send me the details about the failing test cases, if any, to adapt the changes if
necessary?
Regards,
Ulf
Am 12.02.2016 um 08:18 schrieb Jean-Pierre André:
Yes correct, the reason behind is, that I have a problem with ACL encoding.
See my post about: "Swapping order of ACEs significally changes permissions"
I went into this situation, when I had inherited permissions with help
of Windows Explorer.
From Windows side it is not possible to influence the order of the ACEs
in a ACL.
Additionally, the order can change, after manually adding or deleting
permissions from Windows side.
But Windows doesn't care about the order, the resulting rights are
always the same.
The Problem is, that NTFS-3G doesn't do that as well.
Please make a distinction between Windows and the
security GUI in Explorer GUI.
Windows does respect the ACE order when doing an access check,
see for instance :
https://msdn.microsoft.com/en-us/library/aa446683(VS.85).aspx
However there is a known issue with the Explorer GUI. Never allow
it to change the order, because this changes the meaning !
Quoting from : https://cygwin.com/cygwin-ug-net/ntsec.html
Take a note of the last quoted sentence, which is why ntfs-3g
sometimes uses an ACE order which Windows does not like.
Attention is also drawn on that in
http://www.tuxera.com/community/ntfs-3g-advanced/ownership-and-permissions/#limitations
--- quoted ---
All Windows kernels will correctly deal with the ACL regardless of
the order of allow and deny ACEs. The second rule is not modified
to get the ACEs in the preferred order.
Unfortunately the security tab in the file properties dialog of
the Windows Explorer insists to rearrange the order of the ACEs
to canonical order before you can read them. Thank God, the sort
order remains unchanged if one presses the Cancel button. But
don't even think of pressing OK...
Canonical ACLs are unable to reflect each possible combination
of POSIX permissions.
--- unquoted ---
Also, related to Samba, in
https://lists.samba.org/archive/samba-technical/2013-March/091247.html
This is in an inheritance context, maybe this is akin to your issue.
--- quoted ---
While, Windows orders the ACEs in the canonical order, and Samba
does not, however, the failure here might be that Samba is allowing
the inherited flag through when it should not.
--- unquoted ---
This could be changed by simply removing the influence of variable
firstapply in ntfs_build_permissions(...) in acls.c.
So I have to find out, if this would break other things.
Please do and fix it.
You are borrowing too much from my time, so I may have to apply
the Magic Lamp limitations...
Regards
Jean-Pierre
# HG changeset patch
# User Ulf Zibis
# Date 1455920140 -3600
# Fri Feb 19 23:15:40 2016 +0100
# Node ID eeb53d952208e0b9f208834b9df875841e13b5fd
# Parent 08179df8a3fb0196d92100f80ad44995dc4034fd
Added ATTENTION for testing without installing
diff --git a/README b/README
--- a/README
+++ b/README
@@ -113,6 +113,9 @@
And, to end the test, unmount the usual way :
umount /dev/sda1
+ATTENTION: Don't do "cd src" and run from there !!
+ This invokes the existing installed version.
+
NTFS UTILITIES
==============
# HG changeset patch
# User Ulf Zibis
# Date 1455920162 -3600
# Fri Feb 19 23:16:02 2016 +0100
# Node ID 0e7a12f809877f9236c06714e35beb7c87a7d099
# Parent eeb53d952208e0b9f208834b9df875841e13b5fd
Removed ACE order dependency with firstapply
diff --git a/libntfs-3g/acls.c b/libntfs-3g/acls.c
--- a/libntfs-3g/acls.c
+++ b/libntfs-3g/acls.c
@@ -3192,10 +3192,10 @@
int offace;
int acecnt;
int nace;
- BOOL noown;
le32 special;
le32 allowown, allowgrp, allowall;
le32 denyown, denygrp, denyall;
+ BOOL noown;
phead = (const SECURITY_DESCRIPTOR_RELATIVE*)securattr;
offdacl = le32_to_cpu(phead->dacl);
@@ -3281,10 +3281,10 @@
int acecnt;
int nace;
le32 special;
- BOOL grppresent;
- BOOL ownpresent;
le32 allowown, allowgrp, allowall;
le32 denyown, denygrp, denyall;
+ BOOL ownpresent;
+ BOOL grppresent;
phead = (const SECURITY_DESCRIPTOR_RELATIVE*)securattr;
offdacl = le32_to_cpu(phead->dacl);
@@ -3470,11 +3470,10 @@
int offace;
int acecnt;
int nace;
- BOOL firstapply;
- int isforeign;
le32 special;
le32 allowown, allowgrp, allowall;
le32 denyown, denygrp, denyall;
+ int isforeign;
phead = (const SECURITY_DESCRIPTOR_RELATIVE*)securattr;
offdacl = le32_to_cpu(phead->dacl);
@@ -3489,7 +3488,6 @@
acecnt = 0;
offace = 0;
}
- firstapply = TRUE;
isforeign = 3;
for (nace = 0; nace < acecnt; nace++) {
pace = (const ACCESS_ALLOWED_ACE*)&securattr[offace];
@@ -3497,7 +3495,7 @@
&& !(~pace->mask & (ROOT_OWNER_UNMARK | ROOT_GROUP_UNMARK))) {
if ((ntfs_same_sid(usid, &pace->sid)
|| ntfs_same_sid(ownersid, &pace->sid))
- && (((pace->mask & WRITE_OWNER) && firstapply))) {
+ && (pace->mask & WRITE_OWNER)) {
if (pace->type == ACCESS_ALLOWED_ACE_TYPE) {
allowown |= pace->mask;
isforeign &= ~1;
@@ -3520,7 +3518,6 @@
if (pace->type == ACCESS_DENIED_ACE_TYPE)
denyall |= pace->mask;
}
- firstapply = FALSE;
} else
if (!(pace->flags & INHERIT_ONLY_ACE))
if ((ntfs_same_sid((const SID*)&pace->sid,nullsid))
------------------------------------------------------------------------------
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140
_______________________________________________
ntfs-3g-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/ntfs-3g-devel
