Hi Jean-Pierre, Sorry for the late response.
On Mon, Sep 26, 2016 at 01:52:36PM +0200, Jean-Pierre André wrote: > > 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 ? Active Directory objects are stored in a database, not directly on the filesystem. They just happen to both use the security descriptor format. > 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 ? I am not sure what you mean regarding the purpose of ntfs_valid_descr(), but the existing behavior is that it allows unknown ACEs in both the DACL and SACL except in certain cases. And in those certain cases, such as a callback ACE that is not the last ACE in the list, it is broken for backup/restore applications like wimlib which expect to be able to set security descriptors that were created on Windows. Note that as a backup/restore application, wimlib does not want ACE inheritance at all, nor does it want translation of Windows ACLs to POSIX or Linux permissions. It simply wants to stamp a security descriptor on each file or directory. It can be assumed that the security descriptors are valid in the sense that Windows would accept them. As part of this, it can be assumed that the ACEs in each ACL have the common ACE_HEADER. But it can *not* be assumed that every ACE is of a known type. The expected behavior is that unknown ACEs are settable but are then skipped during access evalution. This would match the Windows behavior. I think Windows users might actually find it quite annoying for Windows to do otherwise because then people could not, for example, restore security descriptors intended for a later version of Windows from a live system running an older version of Windows. Essentially the same argument applies to NTFS-3G. With regards to inheritance, as I pointed out Windows simply performs the standard inheritance algorithm on unknown ACEs per the standard ACE_HEADER flags. It's true that there could be special rules that it is missing, but it seems like the most logical behavior and probably the easiest to implement too. Of course, this isn't currently relevant to wimlib which as I mentioned does not care about inheritance. I just thought I'd suggest it as an improvement (though it's still not clear to me what the current behavior is "supposed" to be, and that's part of the problem). Eric ------------------------------------------------------------------------------ The Command Line: Reinvented for Modern Developers Did the resurgence of CLI tooling catch you by surprise? Reconnect with the command line and become more productive. Learn the new .NET and ASP.NET CLI. Get your free copy! http://sdm.link/telerik _______________________________________________ ntfs-3g-devel mailing list ntfs-3g-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ntfs-3g-devel
