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

[Phillip Susi]

Michael B. Trausch wrote:

>NTFS is (and will probably remain) not-so-easy to implement, because
>it's not terribly well documented.  While it might be good to be able to
>read the filesystems after the system is fully stable and such, it might
>not be a good idea to attempt to fully implement it.
>
>  
>
It may be easier to implement our own filesystem, I'm not sure.  At this 
point I kind of doubt it as I believe the linux ntfs project has 
documented NTFS nearly completely.  I also believe that neither fat nor 
ext2/3 satisfies our needs with regards to things like EAs, named data 
streams, and security descriptors. 

>However, on the other side of that, is this:  NTFS is just plain
>*horrible* if you try to gracefully resize it.  Very rarely have I heard
>of an NTFS-resizing operation come out without some form of data loss or
>filesystem corruption.
>
>  
>
Resize using what utility?  Resizing a filesystem is not a function of 
the filesystem itself, but the software used to rebuild it.  The actual 
NTFS format itself actually lends itself quite well to dynamic 
resizing.  All that is required is to extend/retract the $Bitmap file 
accordingly.  I myself have used Norton Ghost many times to create a 
system image and later restore that image to several PCs with larger 
hard drives than the original.  Ghost handled resizing the partition 
flawlessly.  Partition Magic on the other hand, I have seen trash hard 
drives several times. 

>That having been said, ReactOS can't possibly expect to be able to
>dual-boot and subsequently replace Windows on a single partition system.
> It's hard enough to try to convince Linux to boot in a scenerio where
>100% of a hard disk is NTFS and a backup, repartition, reformat, restore
>is not an option.
>  
>
That is because Linux inherently does not like NTFS.  As an NT clone, 
ReactOS does.  Provided that we implement an NTFS driver, installing 
reactos on an existing windows partition and either dual booting or 
replacing windows would be quite feasible. 

>I do think, though, that in the long run, it's safer to just avoid NTFS
>altogether.  It's a huge minefield of messy destruction that could
>probably wait until after the rest of the system has matured, to be
>attacked.  I'd rather move people away from NTFS and closer to something
>like ext3 with advanced ACLs.  EXT3 at the very least is better then
>something like NTFS, because it's open, performs decently well, and has
>support for many different things that NTFS does not.  I think it'd be
>great to have ReactOS have support for it and all of it's features,
>natively, taking advantage of things like the "executable" attribute
>that you give a file, instead of the Windows philosophy that everything
>that's .exe, .cmd, .vbs, .bat, etc., be executable by default.
>  
>
What features does ext3 support?  At the moment I only know of features 
it does NOT support that NTFS does, and we will need.

>Or functionality that when the user (or program on the user's behalf)
>attempted to execute a file, would check the bit and if it wasn't set,
>prompt the user if they'd like to have it set.  This could easily thwart
>systems that rely on blindly executing (such as many of the worms and
>viruses that there are in today's world) from ever seeing the light of
>day, if the system doesn't execute it by default - similar to the
>approach used by firewall systems that prohibit applications and other
>programs from accessing the Internet without first being approved by the
>user (things like Windows XP SP2's firewall, and ZoneLabs Integrity
>Client, do this).
>
>Anyway, I'll hop off of my soapbox.  :-P
>
>	- Mike
>  
>

That is an application issue really.  Specifically web browsers and 
email clients that blindly ShellExecute() files that come from unknown 
sources.  They usually DO warn the user, but users usually ignore the 
warning.  That is why system administrators should configure the machine 
to not execute untrusted programs.