On Tue, May 30, 2006 at 10:11:40AM -0400, Erez Zadok wrote: > Why don't you first start by analyzing ecryptfs's code and propose > how you'd separate stackfs from the core ecryptfs.
I think it is best to consider individual functions that could be
broken out into a generic filesystem. There are several places where I
would like to pass in function pointers to perform various bookkeeping
tasks. Perhaps this could be accomplished with a struct containing
function pointers, like struct stackfs_ops. Wherever there is a place
where a hook would be needed (in the current implementation), I
include commentary on that function:
From ecryptfs_kernel.h:
- struct ecryptfs_*_info
- Additional data structures needed here, such as cryptographic
context for inode objects. A void* member in these structs would
give filesystems what they need to hang arbitrary data
structures off of the filesystem objects (i.e., crypt_stat off
of the inode and mount_crypt_stat off of the superblock).
- ecryptfs_*_to_lower, ecryptfs_*_to_private static inline functions
From main.c:
- ecryptfs_interpose()
- ecryptfs_fill_super()
- ecryptfs_read_super()
- ecryptfs_get_sb()
- Makes a call to parse_options(), which is filesystem-specific.
- ecryptfs_kill_block_super()
- Superblock-specific data structures need releasing; for
instance, in eCryptfs, struct ecryptfs_mount_crypt_stat.
From super.c:
- ecryptfs_alloc_inode()
- Inode-specific data structures need allocation/initialization
here. In eCryptfs, that's struct ecryptfs_crypt_stat.
- ecryptfs_destroy_inode()
- Inode-specific data structures need releasing here. In eCryptfs,
that's struct ecryptfs_crypt_stat.
- ecryptfs_read_inode()
- ecryptfs_put_super()
- struct ecryptfs_mount_crypt_stat needs to be worked on here.
- ecryptfs_statfs()
- ecryptfs_clear_inode()
- ecryptfs_umount_begin()
- ecryptfs_show_options()
- The stackable filesystem may want to insert some additional
options (although eCryptfs doesn't at the moment).
From dentry.c:
- ecryptfs_d_revalidate()
- ecryptfs_d_release()
From inode.c:
- ecryptfs_copy_attr_all()
- ecryptfs_create()
- eCryptfs must perform various operations on the lower file, such
as writing information to the header of the file and setting the
lower file size. This can be hooked at the end of the function.
- ecryptfs_lookup()
- Will need to encrypt the filename (future work).
- eCryptfs reads the file size is read from the header.
- ecryptfs_link()
- ecryptfs_unlink()
- ecryptfs_symlink()
- Will need to encrypt the filename (future work).
- ecryptfs_mkdir()
- ecryptfs_rmdir()
- ecryptfs_mknod()
- ecryptfs_rename()
- ecryptfs_readlink()
- Will need to decrypt the filename (future work).
- ecryptfs_follow_link()
- ecryptfs_put_link()
- ecryptfs_truncate()
- eCryptfs fills in and encrypts 0's when extending past the end
of the file. It also writes the lower file size to the
header. This is called by ecryptfs_setattr() and
ecryptfs_llseek().
- ecryptfs_permission()
- ecryptfs_setattr()
- ecryptfs_setxattr(), ecryptfs_getxattr(), ecryptfs_listxattr(),
ecryptfs_removexattr()
- Will need to encrypt and decrypt the xattr's (future work,
although things will get messy with SE Linux labels, which will
need to be effective for the lower files too).
From file.c:
- ecryptfs_llseek()
- Calls ecryptfs_truncate().
- ecryptfs_read_update_atime()
- ecryptfs_readdir()
- ecryptfs_ioctl()
- ecryptfs_open()
- References the crypt_stat struct several times throughout the
function. Reads and processes header information from the lower
file.
- ecryptfs_flush()
- ecryptfs_release()
- ecryptfs_fsync()
- ecryptfs_fasync()
- ecryptfs_lock()
- ecryptfs_sendfile()
From mmap.c:
- ecryptfs_writepage()
- Calls ecryptfs_encrypt_page().
- ecryptfs_readpage()
- References the crypt_stat struct; calls ecryptfs_decrypt_page().
- ecryptfs_prepare_write()
- ecryptfs_commit_write()
- References the crypt_stat struct. Calls
fill_zeros_to_end_of_page(). Calls
ecryptfs_encrypt_page(). Writes data to the lower file header.
- ecryptfs_bmap()
- ecryptfs_sync_page()
There are a few functions where it may be necessary to have multiple
hooks in the same function. Really, to give a full idea of what kind
of changes would need to happen to eCryptfs, I would have to go ahead
and make a patch to illustrate the changes.
Mike
.___________________________________________________________________.
Michael A. Halcrow
Security Software Engineer, IBM Linux Technology Center
GnuPG Fingerprint: 419C 5B1E 948A FA73 A54C 20F5 DB40 8531 6DCA 8769
"Security experts are an insignificant asset to protect."
- Hans Reiser
signature.asc
Description: Digital signature
_______________________________________________ unionfs mailing list [email protected] http://www.fsl.cs.sunysb.edu/mailman/listinfo/unionfs
