This article can also be found in the Premium Editorial Download "Storage magazine: .NET server storage: Friendly or not?."
Download it now to read this article plus other related content.
Suppose a paranoid employee had an important file they wanted to keep private. They could deny access to everyone except themselves, including the System account. However, what they don't realize is that by doing that, they have made sure that their file won't get backed up either.
Here's a fix
Although an individual user may think that removing access from the Administrator's account will keep his file private, it will only do so as long as the Administrator allows it to stay private. At any time, the Administrator can reset the ACLs on any file within the system.
As with many things in Windows, the difficulty comes in automating Administrator's access from the command line. Ideally, you would run a program that looks for directories and files that have denied access to the System account, and then reset the ACLs on those files. However, I know of no command that's capable of searching for files in this manner. That doesn't mean that such a command doesn't exist. If someone knows of such a command, please let me know.
What you can do is monitor your backup logs. Any decent backup program will create some type of log that will tell you about any files that it couldn't back up. You could look for files that weren't backed up due to ACL issues, and then use the subinacl command from the resource kit to reset them.
Windows alternate data streams
Another issue with Windows NT
The figure below shows how you can make your very own hidden alternate data streams.
C:>echo HIDDEN TEXT >myfile.txt C:>type myfile.txt >visible.txt:hidden.txt C:>type visible.txt C:>more <visible.txt:hidden.txt >lnewfile.txt C:>type newfile.txt HIDDEN TEXT
The first command (echo hidden.txt) creates a file with the text "HIDDEN TEXT." The second command (type myfile.txt) creates the file visible.txt, with the hidden alternate data stream hidden.txt. The hidden stream will contain the text "HIDDEN TEXT." To illustrate this, the next command (type visible.txt) shows that there appears to be nothing in the file visible.txt. However, if we know the name of the alternate data stream, hidden.txt, we can retrieve its contents using the more command. The type newfile.txt command shows that our operation was successful. If you're as curious about this as I was when I first heard about this, there's a free tool called LADS (List Alternate Data Streams) that's available for download at http://www.heysoft.de. This tool shows if you have any files with alternate data streams.
Alternate data streams aren't an issue as long as you don't use them, or if you have a utility that supports the backup and recovery of these streams. The best way to ensure that your backup and recovery utilities supports alternate data streams is to:
- Create a file with an alternate data stream.
- Back it up with your standard backup method.
- Recover the file.
- Use the method shown above to see if the alternate data stream is still there.
Needless to say, alternate data streams don't convert to NFS very well. In fact, they don't even translate to a FAT filesystem. If you copy an alternate data stream file to a FAT filesystem, and then back to an NTFS filesystem, the alternate data streams will be deleted. This means that if your method of backing up a Windows system involves an NFS mount, it will definitely not support the backup and recovery of alternate data streams.
One of the most common statements made by people who find out about alternate data streams (ADS) is, "Gee, that would be a great place for someone to plant a virus!" In addition to talking to your backup and recovery software vendor about ADS, you also might want to talk to your virus protection software vendor about them. If you have a file with a virus that has been quarantined, but still available on your hard drive, you might try using the technique above to place it into an alternate data stream. Then run your virus scan against the new file and make sure that it finds the virus. As long as you don't execute the virus file, you should be fine. But - of course - you do this at your own risk.
I don't want to pretend to be an expert on the various Windows operating systems. I also don't want anyone thinking I'm bashing Windows or Microsoft. My biggest difficulty with these issues is that most people I talk to don't know about them. Hopefully, this article will help clear up some of these issues. If anyone knows any workarounds to any of the issues mentioned in this article, please e-mail me.
This was first published in August 2002