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

[Phillip Susi]

Michael B. Trausch wrote:

>When the system is unmounted, as I understand it, it's marked 'dirty' so
>that the next time you boot into it, Autochk will take a look at it
>before booting.  Except that Autochk doesn't work on any system that
>I've worked on, so I had to create a BartPE disc to check the systems
>occasionally.  Personally, I've never seen that driver wipe away a
>system, but if you were going to start with something, I suppose I'd try
>to start with that one.
>
>  
>
What do you mean autochk does not work?  autochk doesn't do anything for 
NTFS volumes unless you manually force a check.  The entire idea of a 
transactional filesystem is that it will never need a disk checker to be 
run on it after the volume is unmounted in a dirty state. 

>The whole point, however, is that people have tried this and come and
>gone in the past, and it seems terribly daunting.  Is it something that
>can really be done before a major stable version?  If users want to
>convert their data, can't we build a disc for them that will do that,
>and if so wouldn't it be smart to move their data to a partition type
>first, and then install ROS on that partition with the data?  It won't
>necessarily be a one-way-street, as there *are* ways to go back and
>forth, even if they aren't "pretty".
>
>  
>
Converting a partition in place from one format to another isn't really 
any easier than writing a filesystem driver to access it normally.  In 
fact, it is probably harder.  Then the real point is, why would you want 
to convert to a filesystem that does not work as well?

>OTOH, would it be feasible to maybe start with the driver that's been
>written for Linux?  How hard would a Linux driver port to Win32?
>(Something I wouldn't know; I don't work that low-level with either of
>them...)
>
>	- Mike
>  
>
Not really.  The entire operating environment, upper interfaces, and 
lower interfaces for a filesystem driver are radically different on 
Linux than NT. 

Steven Edwards wrote:

>Windows would have this same problem with NTFS on Linux. If I am under Linux and make changes to
>files and create files how does linux-NTFS assign the proper SID and such to the files? This has
>been a long time problem that NTFS has with taking a drive from one Windows box to another. Its
>the same situation and mostly pointless. 99% of new ReactOS are not going to care and the
>resources we get from having a better filesystem now can be put in to developing a NTFS
>replacement.
>  
>
So?  I already said it is a problem translating the other way.  The 
point still is that it is a problem for us to map our views of what a 
filesystem is and can do onto a unix filesystem, so why bother embracing 
those problems which at best, have kludgey solutions. 

>If the ext2fsd supported ext3 journals there would be nothing wrong with using it. I mean hell
>right now ReactOS does not have a security subsystem so this whole discussion is a moot point.
>Unless you feel like implementing lsass =)
>
>Thanks
>Steven
>  
>
There WOULD be a problem with using it, that is what I have been saying 
all along.  It can't efficiently handle the feature set that ReactOS 
expects.  Maybe you can come up with some way to force it to work, but 
at this point, I believe that any such solution is a poor one riddled 
with its own problems, so even if it can be done at all, it is not ideal. 

> Robert Shearman wrote:
> You get the same problems when sharing an NTFS filesystem on a 
> dual-boot system or when moving one between computers, unless the SIDs 
> are well-known.
> I would suggest you check out the Samba presentation at the following 
> URL for information on how Samba4 does NTFS->Unix permissions 
> conversion so you are not stabbing in the dark:
> http://wiki.winehq.org/WineConf
>
> The problem you are describing has already been solved by them in a 
> slightly-not-kludgey way.
>
> Rob
> _______________________________________________


That is not the same problem at all.  The foreign system does recognize 
the file structure, the standard file information, alternate data 
streams, EFS data ( though can not decrypt it obviously ), compressed 
files,  and so on.  With regards to the SIDs in the security 
descriptors, yes, the foreign system does not recognize the unknown SIDs 
but at least it knows that they are unknown SIDs.  On a Linux system 
when you mount a foreign ext partition, the kernel ends up thinking that 
it does understand the uids, but it interprets them wrongly by mapping 
them to random valid users on that system.  For example, Joe owns the 
file on the primary system but when the foreign system mounts the 
volume, Linux thinks that it is owned by Frank who happens to have been 
assigned the same uid.  NT at least recognizes that it has no idea who 
Joe is and doesn't try to claim that Frank owns the file. 

The problems I am referring to are more like when Linux tries to mount a 
FAT filesystem.  There is no security information on the filesystem that 
Linux understands, so what does it do?  Typically it just pretends that 
all the files are owned and are accessible to root with r/w/x access.  
You get the same problem when Linux tries to mount an NTFS volume ( or 
when ReactOS/NT tries to mount an ext volume ).  The information that is 
actually stored on the disk is not consistent with the information that 
the OS can deal with, so the information must somehow be faked or 
translated on the fly, and this causes headaches. 


ea wrote:

> It seems MS engineers already solved the problem. Try installing the 
> full SFU suite (NIS/AD bridge, NFS server etc.) on a Windows Server 
> 2003 DC and look at a file's properties...
> _______________________________________________

I am not able to try this myself so can you explain?



I think that something has been lost in this discussion so I would like 
to restate it.  I do not think that supporting ext is bad, I just think 
that it is not ideal due to the problems involved as a result of the 
disjoint feature sets.  Because it is not ideal, it should not be the 
filesystem of choice.  Because our goal is windows compatibility, NTFS 
implements all the features that we need quite well, and so it is a much 
better choice for a preferred filesystem than ext.  That is not to say 
that there isn't something that may be even better than NTFS, only that 
NTFS is a better choice, all else being equal.