5 ms·
I believe that part of the issue is that the file systems are tailored to the needs of the operating system they run on. Take file permissions. As the basic per
by marcoperaza 9y ago
I believe that part of the issue is that the file systems are tailored to the needs of the operating system they run on. Take file permissions. As the basic permissions model, Linux uses user/group/everyone, while Windows uses ACLs. Linux also supports ACLs but they don't work in the same way that Windows' does. NTFS is built to meet the needs of Windows, while Ext4 is built to meet the needs of Linux. You can use each on the other OS with the right drivers, but just as data drives with very roughly mapped permissions.
- alfredxing 9y agoHmm, that's a good point! However I don't think this would be a major hurdle: file permissions offer OS-level security only, not disk-level security/encryption, so it would still make sense for different OS drivers to implement only their specific permissions attributes.
- thomastjeffery 9y agoTo make your point more clear: NTFS is built for Windows, while every other modern filesystem is made for OS's with Unix-style permissions (including BSDs like OS X).
- tinus_hn 9y agoNote that Windows ACLs are much more powerful than the Unix user/group/world style permissions.
- gerdesj 9y agoThey are, sort of. Linux (at least) can do multiple ACLs per FS object (U/G/W: rwx) whereas NTFS does have a slightly richer set of possible permissions listed when you use the GUI but they really boil down to the same in practice. Novell's NWFS and NSS filesystems have always supported trustee assignments that flow recursively at the point of access rather than the point of administration. Unless you have used either of those as an administrator involving say 1000s of people and groups and millions of files then you will not appreciate this distinction. On both Windows and Linux, if you have to make changes to FS perms, then the ACLs have to be made to each object - file or folder. On NWFS and NSS, you only do it at a point (say a directory) and then it will recurse automatically unless blocked by an IRF (Inheritable Rights Filter - bloody stupid but there if you really need it) The end result is that making a change to a tree of files on any Unix or Windows FS takes from seconds to hours. On NWFS or NSS it generally takes seconds (for the screen to refresh). I have never quite understood why Linux or Windows admins (I'm both) have put up with the rubbish ACLs and implementations of "modern" filesystems. Oooh RAID in software and snapshots - oh how nice. The POSIX ACLs thing is genuinely shit, very outdated and absolute rubbish. This is the 21st century FFS. Why on earth should you wait as each file in a collection that you have deemed as belonging to sales but be readable by fred be stamped as such? Why should users be able to see the path down to a point where they have access? Why on earth should 21st C admins have to watch a change of security requirements take from a few seconds to hours/days? Modern FS's are so NOT 1990s and what a shame.
- ComodoHacker 9y ago>On both Windows and Linux, if you have to make changes to FS perms, then the ACLs have to be made to each object - file or folder. On NWFS and NSS, you only do it at a point (say a directory) and then it will recurse automatically unless blocked by an IRF (Inheritable Rights Filter NTFS has perms inheritance (and overriding) since forever, did you know that? >The end result is that making a change to a tree of files on any Unix or Windows FS takes from seconds to hours. On NWFS or NSS it generally takes seconds (for the screen to refresh). Painless administration requires careful planning, no matter what OS you're using.
- codeulike 9y agoI think the point was that NTFS has to actually touch the files when they inherit permissions, whereas its better for admin if inheritance works without the files needing to be touched
- tinus_hn 9y agoThe inheritable ACLs have to propagate (they can actually get out of sync). This is a design choice; either you check the inherited permissions at file opening or while changing the permissions or creating the file. Chances are you will open the file more often than you will change ACLs so they chose the latter which makes sense.
- ComodoHacker 9y agoInteresting. Do you have any links to read about such implementation details?
- tinus_hn 9y agohttps://support.microsoft.com/en-us/help/320246/inherited-permissions-are-not-automatically-updated-when-you-move-fold https://support.microsoft.com/en-us/help/320246/inherited-pe... This article is about the problems it causes (note that in Vista they changed the design so when moving a subtree the system automatically propagates permissions, removing a major cause of desyncs)
- fetbaffe 9y agoNo, ReFS, a modern file system, does not use Unix-style permissions but ACL like NTFS.
- jussij 9y agoAnd those Windows ACLs form the foundation for higher level Windows security features like Active Directory, which itself is used as a foundation for many other aspects of Windows, so those ACLs are well and truly baked into the OS.
- pjmlp 9y agoActually it goes a bit further than that. Every object in the OS that can be represented by an OS handle, has security permission attached to it. Files, registry, sockets, drivers,.....
- nailer 9y agoLinux has had ACLs in ext4 for a decade now. setfacl g:admins:rw g:staff:r somefile getfacl somefile
- ksk 9y agoWhile you may be correct, those are basic functions that do not compare to what NT has. On Linux, you have to mount the FS with ACL support (I don't know if this is the default now) and manage them in parallel to the file system permissions, complicating the security model (without even going into SELinux and SUID 0 stuff). Due to legacy reasons, Linux's security model has evolved, while NT has had the luxury of a do-over during its design phase.
- nailer 9y agoMy post is correct but you're right. ACLs still aren't default and indedd stuff might break because of that lack of testing.