16 May
2005
16 May
'05
9:18 a.m.
Robert Köpferl wrote:
Actually 'Compression' or the C-bit is one of the file system
capability flags an ifs reports to the IO-manager. So in case of NTFS
this is an FS-feature But it is also possible to write Filter driver
that somehow manages to compress or decompress files (i.e. last part
of name is 7z ). The EFS is implemented like that. It lays over NTFS
devices to add encryption.
If the compression is something that is handled by the file system
driver itself, then would there be a way to make (most, if not all) of
the ReactOS drivers support fs-level compression by making use of one of
the better compression libraries (bz2 or lzma comes to mind). In this
way, each filesystem driver would only be responsible for how to
determine what files are compressed or not, and then passing the
compressed files to the operating system kernel to be decompressed
transparently before an application accesses it.
So, BUT: Please, all, tell me, what are you insisting so much on so
unimportand features like transparent encryption and transparent
compression. In my eyes the first step is to have a FS which is
better than FAT and allows ACLs+EA or xattr+posix-acls (NOTE these
are mostly isomorphisms). Most people can pass on enc+compr at all.
Some use it but they can wait or also pass on it until it can/will be
implemented or not implemented. There exist ways to come around that.
Even GPL. See 7zip and TrueCrypt. For my requirements TrueCrypt beats
NTFS-EFS. So why bother.
Transparent encryption and compression are two highly important things,
IMHO. It's one of those things that probably would be better off being
in the back of someone's mind as they're thinking about how to write the
code that will handle the IFS drivers, or the IFS drivers theirselves.
Also, there are some applications that like to silently try to mark it's
files both, so in a filesystem that supports it, and even Windows
compresses a good bit of %SystemRoot% so that you save space on your
hard disk drive.
I think that it might be smart to have ReactOS create and use a GPG key
on the user's behalf, solely for the purpose of encrypting their
filesystem data when the file owner selects a file to be encrypted on
the filesystem. I think that would be smart, and similar to the
approach that Windows XP uses in having it's EFS "key" that is encrypted
by your Windows XP logon password, be that a local password or your
domain password.
Since GPG is fairly strong encryption technology, with fairly speedy
results, it seems to me like it is a wise choice. Also, it's generally
considered trustworthy by most of those that I have discussed it with.
I'll now prepare a wikipage which handles an injective (but bijective
wanted) translation of acls.
Cool. It ought to be interesting. In the end, I agree with you that
I'd like to see other, non-FAT file systems supported with good
features, such as ACLs and the like, but, since FAT's layout is so
simplistic, it probably makes those drivers the easiest ones to create a
testbed set for since the filesystem isn't terribly complicated.
Just an idea. Again, I will say up-front, that I have no clue with the
code behind ReactOS or the layout of the Win32 API is or would be like
in terms of possibility of the ideas mentioned... but if it can be
interpreted to be that flexible and yet still be compliant, that could
mean a whole new level of security that Windows doesn't (yet) have.
It seems like with some of the rumors going around about Longhorn that
they may be doing something similiar, I know someone at one point fairly
recently told me that they are trying to get rid of the "must be a
Windows administrator to do anything" security problem. Not sure how
much actual low-level FS type work would need to really be done with
that, I would imagine almost none.
- Mike
--
Michael B. Trausch <fd0man(a)gmail.com>
Website: http://fd0man.chadeux.net/ Jabber: mtrausch(a)jabber.com
Phone: +1-(678)-522-7934 FAX (US Only): 1-866-806-4647
===================================================================
Do you have PGP or GPG? Key at pgp.mit.edu, Please Encrypt E-Mail!