[ros-dev] Security policy for FAT partition driver?

[Phillip Susi]

Robert Köpferl wrote:
> I share the opinion that NFFS is a thing we should more less avoid. 
> People are happy if one fs provides reliable access and if it is one 
> which is also accessible by linux, so what's better? ReactOS users will 
> potentially avoid MS-NT

Although I think it is of less importance, I can not disagree on this 
point more.  Most users who will be switching to ReactOS will switching 
from windows, not Linux, and so they will be concerned about NTFS 
compatibility, not ext.  NTFS compatibility will be a desirable feature 
for most ReactOS users, but I see it as a nice feature, but not vitally 
important.  The important reason for using NTFS as I see it, is that I 
do not think other filesystems support the needed features.

> So coming back to ext?.
> There exists a rather good implementation for WinNT: 
> http://www.fs-driver.org/index.html
> better than the italian one. So what's the source of ROS's ext2-IFS in SVN?
> Did we already contact the programmer of the mentioned ext2-ifs?
> Maybe he is willing to add ACL and owner-support and a Posix-EA <-> 
> IBM-EA mapping to his implementation and work with us?

To my knowledge, ext has no way to store NT security descriptors.  You 
may be able to write a hack that say, stores all the descriptors in one 
file, and then has to search that file for the corresponding descriptor 
for every other file on the volume you try to access, but that is an 
ugly hack.

> Issues:
> Owners are 16-bit (since 2.6 also 32-Bit) integers. On NT they are 
> GUIDs. There is some partitioning in DOMAIN and USER for the GUID. 
> However noone hinders us to add a flag to our SM to just use 16  or 32- 
> bit user part for GUIDs to have an easy mapping (also on 
> Ext2,UFS,Reiser...)

User IDs on NT are SIDs, which are not the same as GUIDs.  Technically 
SIDs can have variable length, but all MS windows implementations to 
date have used a 128 bit length consisting of a domain specific part and 
a user specific part.  Mapping this structure back and forth to a 32 bit 
posix uid is an ugly hack, and as such, is less desirable than native 
support.  The same goes for trying to map NT ACLs back and forth to 
posix chmod bits.

> Multiple File streams. NTFS is (looking at the mentioned table) the only 
> FS capable of that feature. But what is it? It is just some semantic to 
> actually hide files having a colon it their name (more less). So such 
> feature can be easyly simulated by a ROS-IFS. OK, there are issues with 
> attributes which then exist several times. But this is in my opinion a 
> minor problem, since no corruption by other OSs can occour (as in FAT).
> And be honest. Who uses this feature?  MS' AppleTalk-Server AND some 
> Virus that hides in another stream.

A number of features use data streams including offline files, EFS, on 
the fly compressed files, and the summary property sheet that lets users 
associate information with files including the author, revision, 
description, and search keywords.  There is also the file OBJID feature 
and reparse points.  I am sure there are more things that rely on this 
feature that I am forgetting about, and I am also sure that there are 
several nice features that we could implement in the future using 
streams, so yes, it is something that we want to support.

In the end, you may be able to hack all the features of NTFS into some 
other filesystem, but it will take a good amount of dirty tricks and so 
won't perform nearly as well.  It is better to go with a filesystem that 
was designed to handle these features rather than come up with kludgey 
ways to force the features into some other filesystem that was not.