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. 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? Eric ------------------------------------------------------------------------------ _______________________________________________ ntfs-3g-devel mailing list ntfs-3g-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ntfs-3g-devel
