Ulf Zibis wrote: > 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
No it does not emulate Posix mode, on the contrary, the Posix mode has to use the officially defined rules supported by Windows in a way which the Windows administration tools dislike. Cygwin and Samba are also faced with this issue which they solve in a similar way. > 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? It does not pass the "secaudit -t" test (which you have), at least when Posix ACLs are in use. [linux@dimension acls]$ ./secaudit -t secaudit 1.4.6 : NTFS security data auditing 4096 ACLs built from mode, 27800 ACE built, mean count 6.78 4096 ACLs built from Posix ACLs, 27800 ACE built, mean count 6.78 4096 ACLs built from mode, 31896 ACE built, mean count 7.78 4096 ACLs built from Posix ACLs, 31896 ACE built, mean count 7.78 ** wrong permission settings, kind 2 perm 0000, gotback 700 ** wrong permission settings, kind 2 perm 0001, gotback 701 ** wrong permission settings, kind 2 perm 0002, gotback 702 ** wrong permission settings, kind 2 perm 0003, gotback 703 ** wrong permission settings, kind 2 perm 0004, gotback 704 ** wrong permission settings, kind 2 perm 0005, gotback 705 ** wrong permission settings, kind 2 perm 0006, gotback 706 ** wrong permission settings, kind 2 perm 0007, gotback 707 ** wrong permission settings, kind 2 perm 0010, gotback 710 ** wrong permission settings, kind 2 perm 0011, gotback 711 10 ACLs built from mode, 50 ACE built, mean count 5.00 ** Error : ACE count 50 instead of 24064 ** Error : wrong global hash 0xbc981d00 instead of 0x8fd9ecfe 10 ACLs built from Posix ACLs, 50 ACE built, mean count 5.00 ** Error : ACE count 50 instead of 24064 ** Error : wrong global hash 0xbc981d00 instead of 0x8fd9ecfe ** too many errors, test aborted And it is a recommended pratice not to send a full test database to a developer, in order to prevent him from trying to pass the test instead of solving the requirement (there is a recent case about a manufacturer who solved passing the tests instead of complying with the regulations). Note : if removing the firstapply solve your issue, that is good for you.... Jean-Pierre > > 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 >> >> >> >> > ------------------------------------------------------------------------------ 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 ntfs-3g-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ntfs-3g-devel
