Hi Eric, Eric Biggers wrote: > On Wed, Sep 21, 2016 at 12:01:23PM +0200, Jean-Pierre André wrote: >> >> I have never met an object ACE and they might be irrelevant >> for a file system which only deals with files and directories. >> >> Is there a point in ntfs-3g accepting ACE types controlling >> entities which are not emulated on Linux (callbacks, labels, >> policies, etc.) ? > > Yes, because it should be --- and already is, except in certain cases --- > possible to use NTFS-3G to restore security descriptors that were created > under > Windows. This can be done by using wimlib to extract a WIM image to a NTFS > volume (for example). > > I think the emulation of ACEs under Linux is a separate concern which for some > of the new ACE types isn't really possible or meaningful. > > I also did some research, and some experiments on Windows: > > 1. "Object" ACEs are mentioned as only being used for Active Directory objects > [source: Windows Internals 6th edition]. On Windows, trying to use > SetFileSecurity() to set an object ACE in the DACL of an NTFS directory > fails > with ERROR_INVALID_ACL. This is different from how Windows treats truly > unknown ACE types (see below). But I think it would be fine for NTFS-3G > to > simplify things by treating object ACEs like any other unknown ACE type.
Just for me to understand : Unix stores special objects (such as pipes, sockets, etc.) as file system objects with access control attached. Does Windows also records special objects as file system objects ? If so, how are these objects distinguished from files and directories ? > 2. "Callback" ACEs, also known as "conditional" ACEs, are mentioned as only > existing for use by the AuthZ API, which is a userspace API for access > control. The Windows kernel does *not* evaluate such ACEs when performing > access checks [source: Windows Internals 6th edition]. However, I *was* > able > to set such an ACE in the DACL of an NTFS directory using > SetFileSecurity(). > In addition, on Windows such an ACE is inherited per the standard ACE > header > flags, and the generic rights and SID mapping is performed. Still, I > don't > yet know exactly *why* recent Windows 10 builds have been observed to use > such ACEs. > > 3. Truly unknown ACE types are accepted by SetFileSecurity(). They also are > inherited per the standard ACE header flags. However, they are not > evaluated > during access checks. In addition, SetFileSecurity() does no validation > of > the ACCESS_MASK or SID fields of unknown ACEs --- which makes sense > because > the format of such ACEs is actually unknown beyond the ACE_HEADER. > Instead, > the ACE size field simply required to be at least sizeof(ACE_HEADER) and a > multiple of 4. No generic rights or SID mapping is performed during > inheritance of unknown ACEs. > > So, given the requirements and these observations, I'd like to propose that > NTFS-3G handle unknown ACE types as follows: > > * ntfs_valid_descr() accepts them and check the size only (like Windows) > * ntfs_inherit_acl() performs inheritance on unknown ACE types per the ACE > header flags but without the generic mapping (like Windows). Optionally, > generic rights and SID mapping can be done for callback ACEs. > * NTFS-3G otherwise ignores unknown ACEs (like Windows) > > Any thoughts on this? The purpose of ntfs_valid_descr() is to reject descriptors which ntfs-3g cannot process properly. I am not keen on letting special ACEs leaking into translations to Linux. Inheritance is of particular concern, because this is rather complex and there are undocumented special cases which have to be found by trials and errors. Moreover the result is generally not satisfactory for Linux users who have expectations different from Windows ones (typical example : inheritance of execute permissions). Also : if objects can inherit special ACEs from their parent directory, what prevents them to be inherited to plain files created in the same directory ? Cannot these specific needs be implemented within wimlib ? Jean-Pierre ------------------------------------------------------------------------------ _______________________________________________ ntfs-3g-devel mailing list ntfs-3g-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ntfs-3g-devel
