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

[Kenn Humborg]

On Mon, Apr 12, 2004 at 01:16:56PM -0700, Bill Stackpole wrote:
> --- Kenn Humborg <kenn at linux.ie> wrote:
> > On Sat, Apr 10, 2004 at 08:21:03AM -0700, Bill
> > Stackpole wrote:
> 
> <snip>
> 
> > 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.
> 
> ***
> Ken,
> Your contention is true with respect to the person
> actually IMPLEMENTING the change (e.g. that person
> will already have read access to all files in
> question.) However my position is based on the reasons
> one might use an NTFS-based filesystem in the first
> place - that is, to limit access to OTHER users on the
> system. 
> 
> My contention is that *should* one translate the
> contents from NTFS to FATxx and make the drive
> available over the network (leaving the files in the
> FATxx filesystem with no security controls) one might
> enable the formerly-protected files to be accessed by
> an unauthorized individual. Nuff said.
> ***

Bil,

Then you'd probably want to object to the cacls.exe included
with Windows NT, 2000 and XP.  Run that commmand with the
right options (or maybe I should say "wrong options :-),
and your formerly-accessible files are no longer protected.

Don't blame the tool for the stupidity of the user.

The original poster was looking for a way to convert an NTFS
partition to FAT so that he could access it from multiple
operating systems on the same machine.  I'd be fairly sure
he knows what he is doing.

> I was pretty sure I had read that the MFT entry for a
> file is accessible (for a "file open" command) via a
> stream number. My logic is that if one is able to open
> the metadata part of a file with a Microsoft
> programming tool using a numerical value represented
> in a stream-like format, one might consider that
> metadata part of the file to be a stream-like
> structure. Again, this is not something I have DONE,
> it's something I have READ.
> To resolve this particular question, lets ask for some
> additional feedback:
> OPEN REQUEST - Any programmers out there who have
> direct experience reading/writing to NTFS streams -
> and specifically the metadata stream - who might
> address these questions? - END OPEN REQUEST

Perhaps you are thinking of this (URL wrapped):

   http://msdn.microsoft.com/library/default.asp?url=/library/en-us/
     stg/stg/ipropertysetstorage_ntfs_file_system_implementation.asp

In 2000 and later, you can set extended properties even for 
non-OLE-compound-document files:

   http://msdn.microsoft.com/library/en-us/dnfiles/html/ntfs03.gif

These get stored in alternate streams (seemingly called
:VersionInfo, :VersionInfoEx and :Document Summary Info).

But these have nothing to do with the filesystem-level metadata.

> I will agree that NTFS uses a Master File Table (MFT)
> to manage the permissions for each file. I will
> further grant you that the MFT entry for a file
> *could* be thought of as something similar to an inode
> in UFS. However I believe this comparison to be
> misleading and generally discourage such talk for the
> following reason: If one compares the the MFT entry
> for a file in NTFS and the inode in UFS, one will find
> the existence of a FILENAME in the MFT which has no
> such equivalent in a UFS inode. 

I'll accept that I was a bit cavalier with the mataphor.

> *** 
> I agree. You are correct - there is nothing to stop
> one from creating files based on your naming
> convention (or using some alternative.) To keep
> everything straight, one would have to ensure an
> intelligent and logical approach. 
> 
> I believe that prior to copying existing streams, one
> would have to KNOW the data streams exist, AND know
> their NAMES in order to copy them. (I'm willing to
> accept corrections to this belief as well.)

The win32 API BackupRead() will tell you this.  Mentioned
briefly here:

   http://msdn.microsoft.com/library/default.asp?url=/library/
      en-us/dnfiles/html/ntfs5.asp

Later,
Kenn