[ILUG] Re: contents of ILUG Digest, Vol 16, Issue 43

[Kenn Humborg]

On Sat, Apr 10, 2004 at 08:21:03AM -0700, Bill Stackpole wrote:
> Since no such information (e.g.
> owner/group/permissions) are available in a FAT (File
> Allocation Table) based f/sys, allowing the content of
> an NTFS f/sys to be translated would strip off all the
> security functionality provided by NTFS - leaving the
> contents of potentially sensitive files vulnerable to
> anyone with a set of tools they could use to translate
> the filesystem. 

This is not a valid argument against the existence of such 
a tool.  To run this tool, the user already needs full
read access (at a minimum) to the contents of the NTFS
file system.  If they have this, all "potentially sensitive"
files are already compromised.

> Further, the way the NTFS f/sys stores each of the
> parts to a given file is through a series of
> structures called "data streams" (the concept of which
> doesn't lend itself to existence in a FAT-based
> f/sys). 

This is true.

> A single file in an NTFS f/sys generally
> contains the permission and ownership information in
> one "stream", ...

But I really don't think this is true.

> ... the data content in another "stream",
> while even more "streams" can exist (or be created) to
> contain further data or information. 

AIUI, the ownership and permissions (i.e. the security descriptor
for the file) are stored in the equivalent of the inode
(i.e. the master file table entry for the file).

I've real quite a bit about the use of multiple streams in
NTFS files in Microsoft documentation, yet I've _never_ seen
them say that the security descriptor was stored in an 
alternate stream).

> If a file in an
> NTFS f/sys was to be simply copied to a FAT-based
> f/sys, only the FIRST data "stream" is moved (the
> remaining streams have no logical place to be stored
> in a FAT-based system and as such, are lost.) 

There is nothing stopping such a conversion tool from
converting the alternate streams to separate files on 
the FAT filesystem, with a suitable naming convention
such as FILE.EXT, FILE.EXT.STREAM2, FILE.EXT.STREAM3,...

> I would be willing to bet that if you asked an equal
> number of Sys-admins, folks involved in f/sys or OS
> development, and computer security personnel, most of
> those folks would tell you that it wouldn't be a good
> idea to translate to FAT from NTFS, should any tools
> actually be available to do so.

Well, I fall into all three of those camps you've mentioned
and I have absolutely no objection to such a tool.  I wouldn't
expect that an NTFS-to-FAT tool would necessarily allow
round-tripping (i.e. convert to FAT and back to NTFS without
losing information), but it would be possible if the security
descriptors, alternate streams and other NTFS features were
stored into additional files on the FAT fs.

> BTW, If you get any alternative answers to your
> question, I'd be interested to hear them (e.g. anyone
> who knows of tools that would allow such a
> translation.)

I think the difficulty with an NTFS-to-FAT conversion is
doing it in-place.  AIUI, one of the design criteria in NTFS
was in-place conversion from FAT, so the on-disk structures are
layed out such that you can safely convert from FAT to NTFS.
(It might not be an optimally-laid-out filesystem, but it works.)
However, it is very possible that the layout requirements of
FAT prevent a reliable conversion in the opposite direction.

This suggests that Partition Magic can do NTFS-to-FAT conversions
but is not 100% reliable.

   http://www.experts-exchange.com/Operating_Systems/Q_20695721.html

Later,
Kenn