Hi, Ulf Zibis wrote: > Hi Jean-Pierre, > > thanks again. > > Am 11.02.2016 um 08:25 schrieb Jean-Pierre André: >>> Much thanks for the testing. I should have introduced a bug. >>> How can I run the self-testing my self. I see some conditional test >>> code, but I don't find any hint, how to use it. >> >> Define the macro SELFTEST > > I guess, you mean? : > > #define SELFTESTS 1 /* include code for self-testing */ > > But this doesn't help, as there is always: > > #if SELFTESTS & !USESTUBS > > But USESTUBS is also set with: > > #ifdef HAVE_CONFIG_H > #undef POSIXACLS /* override default by configure option */ > #define USESTUBS 1 /* API stubs generated at link time */ > #else > #define USESTUBS 0 /* direct calls to API, based on following definitions */ > #define ENVNTFS3G "NTFS3G" > #define LIBFILE64 "/lib64/libntfs-3g.so.4921" > #define LIBFILE "/lib/libntfs-3g.so.4921" > #endif > > So it seems, that I have to unset HAVE_CONFIG_H. > > Should I do this, and how? > I'm not sure about the impact from defining ENVNTFS3G, LIBFILE64 and > LIBFILE which will happen then.
Yes : secaudit is designed to run in various conditions, and you have to fiddle with them. So, get to the basics (you may have to fix minor things, there are buggy versions around) : gcc -O2 -ldl -o secaudit acls.c secaudit.c > > I also have problems to run the locally compiled ntfs-3g.secaudit for > test without installing it on my system. > If I run /src/ntfs-3g.secaudit/, I always see the results from the > installed version. > > How can I manage to run the just-built uninstalled binaries? This is described in the distributed readme. > >>>> >>>> Finally, how did you get into the condition you are trying to fix ? >>> >>> There are 2: >>> - broken indentation makes it more difficult to me to understand the >>> code. >>> - redundancy makes it more difficult to me to understand the code. >>> >> >> I was asking what you were trying to fix, because I thought you had >> hidden something about about fixing some ACL encoding or decoding >> issue. If this is not the case, I am not interested. > > 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
