[cap-talk] Polaris in CACM

Stiegler, Marc D marc.d.stiegler at hp.com
Tue Sep 5 13:02:55 CDT 2006


> Why did you choose copying/synchronizing files instead of a 
> file system filter driver?
> 
> Wes Felter

We looked briefly at the very beginning of Polaris development at
creating, not a file system filter driver, but our own file system
driver. That was beyond the expertise available to us at that time, and
we needed a quick solution.

I had never heard of a "file system filter driver" until you mentioned
it here. Examining it briefly, I cannot tell if it would have met our
needs. Here are a couple of the complicated requirements that syncing
provides that are hard (though not impossible) to achieve by other
means:

-- Polaris must be able to not merely enable the shutting off access to
a file, but it must also be able to grant access to a file that the
pet's restricted user account does not have access to. One of the
specific requirements that drove us to a copy/sync was the requirement
that the pet accounts, which are local accounts, be able to access, in a
fine-grain fashion, network file shares for which the true user has
read/write authority, but does not have acl-editing authority. Enabling
a local account to edit a network share with fine grain permissions is,
uh, tricky.

-- Different applications have very different strategies for saving
their documents. One of the most important doc-saving algorithms to
enable is the strategy used by MS-Office. That algorithm is:
    - hold a write lock on the document being edited
    - save the new version of the doc to a temp file in the original doc
directory
    - rename the original doc
    - rename the temp to the original doc name, continue to hold a write
lock on it
    - delete the old version of the doc

A key item is, the creation of the temp file in the original doc
directory. It might look harmless to allow an app to create a temp file
in the user's actual directory, but there is no reliable method for
distinguishing a "temp file" from an attack file that is placed into the
user directory just to lure the user into opening it up some time, with
all the user's authority. So one must allow the app to write the temp
files (else it will crash), but one must not allow the app to write the
temp files to the user directory. Copy/sync does this automagically, the
temp files go into the folder with the doc copy, not the doc original.

Anyway, after Tyler joined the team and learned some of the deep
mysteries of Windows, we identified another technique, specific to
Windows, superior to copy/sync in almost every way, too late for the
Beta release, for which we are currently filing a patent. Copy sync
works well enough that I would recommend to HP that, if they decide to
ship a Polaris product, they should still use copy/sync, but the
advanced strategy might be a good idea for a version 2.

--marcs



More information about the cap-talk mailing list