[Ecryptfs-devel] [PATCH] eCryptfs: Use generic_file_splice_read()
eCryptfs is currently just passing through splice reads to the lower
filesystem. This is obviously incorrect behavior; the decrypted data
is what needs to be read, not the lower encrypted data. I cannot think
of any good reason for eCryptfs to implement splice_read, so this
patch points the eCryptfs fops splice_read to use
generic_file_splice_read.
Signed-off-by: Michael Halcrow [EMAIL PROTECTED]
--- linux-2.6.23-rc4-mm1.orig/fs/ecryptfs/file.c
+++ linux-2.6.23-rc4-mm1/fs/ecryptfs/file.c
@@ -338,21 +338,6 @@ static int ecryptfs_fasync(int fd, struc
return rc;
}
-static ssize_t ecryptfs_splice_read(struct file *file, loff_t * ppos,
- struct pipe_inode_info *pipe, size_t count,
- unsigned int flags)
-{
- struct file *lower_file = NULL;
- int rc = -EINVAL;
-
- lower_file = ecryptfs_file_to_lower(file);
- if (lower_file-f_op lower_file-f_op-splice_read)
- rc = lower_file-f_op-splice_read(lower_file, ppos, pipe,
- count, flags);
-
- return rc;
-}
-
static int ecryptfs_ioctl(struct inode *inode, struct file *file,
unsigned int cmd, unsigned long arg);
@@ -365,7 +350,7 @@ const struct file_operations ecryptfs_di
.release = ecryptfs_release,
.fsync = ecryptfs_fsync,
.fasync = ecryptfs_fasync,
- .splice_read = ecryptfs_splice_read,
+ .splice_read = generic_file_splice_read,
};
const struct file_operations ecryptfs_main_fops = {
@@ -382,7 +367,7 @@ const struct file_operations ecryptfs_ma
.release = ecryptfs_release,
.fsync = ecryptfs_fsync,
.fasync = ecryptfs_fasync,
- .splice_read = ecryptfs_splice_read,
+ .splice_read = generic_file_splice_read,
};
static int
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
eCryptfs-devel mailing list
eCryptfs-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ecryptfs-devel
[Ecryptfs-devel] [PATCH 6/11] eCryptfs: Update metadata read/write functions
Update the metadata read/write functions and grow_file() to use the
read_write.c routines. Do not open another lower file; use the
persistent lower file instead. Provide a separate function for
crypto.c::ecryptfs_read_xattr_region() to get to the lower xattr
without having to go through the eCryptfs getxattr.
Signed-off-by: Michael Halcrow [EMAIL PROTECTED]
---
fs/ecryptfs/crypto.c | 126 +++--
fs/ecryptfs/ecryptfs_kernel.h | 15 +++--
fs/ecryptfs/file.c|2 +-
fs/ecryptfs/inode.c | 101 +++--
fs/ecryptfs/mmap.c|2 +-
5 files changed, 113 insertions(+), 133 deletions(-)
diff --git a/fs/ecryptfs/crypto.c b/fs/ecryptfs/crypto.c
index d6a0680..6b4d310 100644
--- a/fs/ecryptfs/crypto.c
+++ b/fs/ecryptfs/crypto.c
@@ -1344,21 +1344,28 @@ out:
return rc;
}
-int ecryptfs_read_and_validate_header_region(char *data, struct dentry *dentry,
-struct vfsmount *mnt)
+int ecryptfs_read_and_validate_header_region(char *data,
+struct inode *ecryptfs_inode)
{
+ struct ecryptfs_crypt_stat *crypt_stat =
+ (ecryptfs_inode_to_private(ecryptfs_inode)-crypt_stat);
int rc;
- rc = ecryptfs_read_header_region(data, dentry, mnt);
- if (rc)
+ rc = ecryptfs_read_lower(data, 0, crypt_stat-extent_size,
+ecryptfs_inode);
+ if (rc) {
+ printk(KERN_ERR %s: Error reading header region; rc = [%d]\n,
+ __FUNCTION__, rc);
goto out;
- if (!contains_ecryptfs_marker(data + ECRYPTFS_FILE_SIZE_BYTES))
+ }
+ if (!contains_ecryptfs_marker(data + ECRYPTFS_FILE_SIZE_BYTES)) {
rc = -EINVAL;
+ ecryptfs_printk(KERN_DEBUG, Valid marker not found\n);
+ }
out:
return rc;
}
-
void
ecryptfs_write_header_metadata(char *virt,
struct ecryptfs_crypt_stat *crypt_stat,
@@ -1443,24 +1450,18 @@ static int ecryptfs_write_headers_virt(char *page_virt,
size_t *size,
static int
ecryptfs_write_metadata_to_contents(struct ecryptfs_crypt_stat *crypt_stat,
- struct file *lower_file, char *page_virt)
+ struct dentry *ecryptfs_dentry,
+ char *page_virt)
{
- mm_segment_t oldfs;
int current_header_page;
int header_pages;
- ssize_t size;
- int rc = 0;
+ int rc;
- lower_file-f_pos = 0;
- oldfs = get_fs();
- set_fs(get_ds());
- size = vfs_write(lower_file, (char __user *)page_virt, PAGE_CACHE_SIZE,
-lower_file-f_pos);
- if (size 0) {
- rc = (int)size;
- printk(KERN_ERR Error attempting to write lower page;
- rc = [%d]\n, rc);
- set_fs(oldfs);
+ if ((rc = ecryptfs_write_lower(ecryptfs_dentry-d_inode, page_virt,
+ 0, PAGE_CACHE_SIZE))) {
+ printk(KERN_ERR %s: Error attempting to write header
+ information to lower file; rc = [%d]\n, __FUNCTION__,
+ rc);
goto out;
}
header_pages = ((crypt_stat-extent_size
@@ -1469,18 +1470,19 @@ ecryptfs_write_metadata_to_contents(struct
ecryptfs_crypt_stat *crypt_stat,
memset(page_virt, 0, PAGE_CACHE_SIZE);
current_header_page = 1;
while (current_header_page header_pages) {
- size = vfs_write(lower_file, (char __user *)page_virt,
-PAGE_CACHE_SIZE, lower_file-f_pos);
- if (size 0) {
- rc = (int)size;
- printk(KERN_ERR Error attempting to write lower page;
- rc = [%d]\n, rc);
- set_fs(oldfs);
+ loff_t offset;
+
+ offset = (current_header_page PAGE_CACHE_SHIFT);
+ if ((rc = ecryptfs_write_lower(ecryptfs_dentry-d_inode,
+ page_virt, offset,
+ PAGE_CACHE_SIZE))) {
+ printk(KERN_ERR %s: Error attempting to write header
+ information to lower file; rc = [%d]\n,
+ __FUNCTION__, rc);
goto out;
}
current_header_page++;
}
- set_fs(oldfs);
out:
return rc;
}
@@ -1500,7 +1502,6 @@ ecryptfs_write_metadata_to_xattr(struct dentry
*ecryptfs_dentry,
/**
* ecryptfs_write_metadata
* @ecryptfs_dentry: The eCryptfs dentry
- * @lower_file: The lower file struct, which was returned from dentry_open
*
* Write the file headers out. This will likely involve
[Ecryptfs-devel] [PATCH 8/11] eCryptfs: Convert mmap functions to use persistent file
Convert readpage, prepare_write, and commit_write to use read_write.c
routines. Remove sync_page; I cannot think of a good reason for
implementing that in eCryptfs.
Signed-off-by: Michael Halcrow [EMAIL PROTECTED]
---
fs/ecryptfs/mmap.c | 199 +++-
1 files changed, 103 insertions(+), 96 deletions(-)
diff --git a/fs/ecryptfs/mmap.c b/fs/ecryptfs/mmap.c
index 60e635e..dd68dd3 100644
--- a/fs/ecryptfs/mmap.c
+++ b/fs/ecryptfs/mmap.c
@@ -267,9 +267,78 @@ static void set_header_info(char *page_virt,
}
/**
+ * ecryptfs_copy_up_encrypted_with_header
+ * @page: Sort of a ``virtual'' representation of the encrypted lower
+ *file. The actual lower file does not have the metadata in
+ *the header.
+ * @crypt_stat: The eCryptfs inode's cryptographic context
+ *
+ * The ``view'' is the version of the file that userspace winds up
+ * seeing, with the header information inserted.
+ */
+static int
+ecryptfs_copy_up_encrypted_with_header(struct page *page,
+ struct ecryptfs_crypt_stat *crypt_stat)
+{
+ loff_t extent_num_in_page = 0;
+ loff_t num_extents_per_page = (PAGE_CACHE_SIZE
+ / crypt_stat-extent_size);
+ int rc = 0;
+
+ while (extent_num_in_page num_extents_per_page) {
+ loff_t view_extent_num = ((page-index * num_extents_per_page)
+ + extent_num_in_page);
+
+ if (view_extent_num crypt_stat-num_header_extents_at_front) {
+ /* This is a header extent */
+ char *page_virt;
+
+ page_virt = kmap_atomic(page, KM_USER0);
+ memset(page_virt, 0, PAGE_CACHE_SIZE);
+ /* TODO: Support more than one header extent */
+ if (view_extent_num == 0) {
+ rc = ecryptfs_read_xattr_region(
+ page_virt, page-mapping-host);
+ set_header_info(page_virt, crypt_stat);
+ }
+ kunmap_atomic(page_virt, KM_USER0);
+ flush_dcache_page(page);
+ if (rc) {
+ ClearPageUptodate(page);
+ printk(KERN_ERR %s: Error reading xattr
+ region; rc = [%d]\n, __FUNCTION__, rc);
+ goto out;
+ }
+ SetPageUptodate(page);
+ } else {
+ /* This is an encrypted data extent */
+ loff_t lower_offset =
+ ((view_extent_num -
+ crypt_stat-num_header_extents_at_front)
+* crypt_stat-extent_size);
+
+ rc = ecryptfs_read_lower_page_segment(
+ page, (lower_offset PAGE_CACHE_SHIFT),
+ (lower_offset ~PAGE_CACHE_MASK),
+ crypt_stat-extent_size, page-mapping-host);
+ if (rc) {
+ printk(KERN_ERR %s: Error attempting to read
+ extent at offset [%lld] in the lower
+ file; rc = [%d]\n, __FUNCTION__,
+ lower_offset, rc);
+ goto out;
+ }
+ }
+ extent_num_in_page++;
+ }
+out:
+ return rc;
+}
+
+/**
* ecryptfs_readpage
- * @file: This is an ecryptfs file
- * @page: ecryptfs associated page to stick the read data into
+ * @file: An eCryptfs file
+ * @page: Page from eCryptfs inode mapping into which to stick the read data
*
* Read in a page, decrypting if necessary.
*
@@ -277,59 +346,35 @@ static void set_header_info(char *page_virt,
*/
static int ecryptfs_readpage(struct file *file, struct page *page)
{
+ struct ecryptfs_crypt_stat *crypt_stat =
+
ecryptfs_inode_to_private(file-f_path.dentry-d_inode)-crypt_stat;
int rc = 0;
- struct ecryptfs_crypt_stat *crypt_stat;
- BUG_ON(!(file file-f_path.dentry file-f_path.dentry-d_inode));
- crypt_stat = ecryptfs_inode_to_private(file-f_path.dentry-d_inode)
- -crypt_stat;
if (!crypt_stat
|| !(crypt_stat-flags ECRYPTFS_ENCRYPTED)
|| (crypt_stat-flags ECRYPTFS_NEW_FILE)) {
ecryptfs_printk(KERN_DEBUG,
Passing through unencrypted page\n);
- rc = ecryptfs_do_readpage(file, page, page-index);
- if (rc) {
- ecryptfs_printk(KERN_ERR, Error reading page; rc =
- [%d]\n, rc
[Ecryptfs-devel] [PATCH 9/11] eCryptfs: Initialize persistent lower file on inode create
Initialize persistent lower file on inode create.
Signed-off-by: Michael Halcrow [EMAIL PROTECTED]
---
fs/ecryptfs/super.c | 13 +++--
1 files changed, 7 insertions(+), 6 deletions(-)
diff --git a/fs/ecryptfs/super.c b/fs/ecryptfs/super.c
index b97e210..f8cdab2 100644
--- a/fs/ecryptfs/super.c
+++ b/fs/ecryptfs/super.c
@@ -47,15 +47,16 @@ struct kmem_cache *ecryptfs_inode_info_cache;
*/
static struct inode *ecryptfs_alloc_inode(struct super_block *sb)
{
- struct ecryptfs_inode_info *ecryptfs_inode;
+ struct ecryptfs_inode_info *inode_info;
struct inode *inode = NULL;
- ecryptfs_inode = kmem_cache_alloc(ecryptfs_inode_info_cache,
- GFP_KERNEL);
- if (unlikely(!ecryptfs_inode))
+ inode_info = kmem_cache_alloc(ecryptfs_inode_info_cache, GFP_KERNEL);
+ if (unlikely(!inode_info))
goto out;
- ecryptfs_init_crypt_stat(ecryptfs_inode-crypt_stat);
- inode = ecryptfs_inode-vfs_inode;
+ ecryptfs_init_crypt_stat(inode_info-crypt_stat);
+ mutex_init(inode_info-lower_file_mutex);
+ inode_info-lower_file = NULL;
+ inode = inode_info-vfs_inode;
out:
return inode;
}
--
1.5.1.6
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
eCryptfs-devel mailing list
eCryptfs-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ecryptfs-devel
Re: [Ecryptfs-devel] [PATCH 3/11] eCryptfs: read_write.c routines
On Wed, Sep 19, 2007 at 10:38:50PM -0700, Andrew Morton wrote:
+ virt = kmap(page_for_lower);
+ rc = ecryptfs_write_lower(ecryptfs_inode, virt, offset, size);
+ kunmap(page_for_lower);
+ return rc;
+}
argh, kmap. http://lkml.org/lkml/2007/9/15/55
Here is a patch that moves to kmap_atomic(), adding an intermediate
copy. Although I would really like to find a way to avoid having to do
this extra copy.
---
Replace kmap() with kmap_atomic() for read_write.c routines
kmap() can lead to deadlock when multiple tasks attempt to take more
than one simultaneously:
http://lkml.org/lkml/2007/9/15/55
In order to avoid this possibility, eCryptfs must allocate an
intermediate block of memory to use with vfs_read() and vfs_write(),
copying the data through this memory region, since kmap_atomic()
cannot be held during calls which may block.
Signed-off-by: Michael Halcrow [EMAIL PROTECTED]
---
diff --git a/fs/ecryptfs/ecryptfs_kernel.h b/fs/ecryptfs/ecryptfs_kernel.h
index bb92b74..ce7a5d4 100644
--- a/fs/ecryptfs/ecryptfs_kernel.h
+++ b/fs/ecryptfs/ecryptfs_kernel.h
@@ -648,6 +648,6 @@ int ecryptfs_read_lower_page_segment(struct page
*page_for_ecryptfs,
struct inode *ecryptfs_inode);
int ecryptfs_read(char *data, loff_t offset, size_t size,
struct file *ecryptfs_file);
-struct page *ecryptfs_get1page(struct file *file, loff_t index);
+struct page *ecryptfs_get_locked_page(struct file *file, loff_t index);
#endif /* #ifndef ECRYPTFS_KERNEL_H */
diff --git a/fs/ecryptfs/mmap.c b/fs/ecryptfs/mmap.c
index c6a8a33..6abf805 100644
--- a/fs/ecryptfs/mmap.c
+++ b/fs/ecryptfs/mmap.c
@@ -37,23 +37,30 @@
struct kmem_cache *ecryptfs_lower_page_cache;
/**
- * ecryptfs_get1page
+ * ecryptfs_get_locked_page
*
* Get one page from cache or lower f/s, return error otherwise.
*
- * Returns unlocked and up-to-date page (if ok), with increased
+ * Returns a locked and up-to-date page (if ok), with increased
* refcnt.
*/
-struct page *ecryptfs_get1page(struct file *file, loff_t index)
+struct page *ecryptfs_get_locked_page(struct file *file, loff_t index)
{
struct dentry *dentry;
struct inode *inode;
struct address_space *mapping;
+ struct page *page;
dentry = file-f_path.dentry;
inode = dentry-d_inode;
mapping = inode-i_mapping;
- return read_mapping_page(mapping, index, (void *)file);
+ page = read_mapping_page(mapping, index, (void *)file);
+ if (!IS_ERR(page))
+ lock_page(page);
+ else
+ printk(KERN_ERR %s: Error from read_mapping_page()\n,
+ __FUNCTION__);
+ return page;
}
/**
diff --git a/fs/ecryptfs/read_write.c b/fs/ecryptfs/read_write.c
index ccd2599..6732a4c 100644
--- a/fs/ecryptfs/read_write.c
+++ b/fs/ecryptfs/read_write.c
@@ -83,14 +83,24 @@ int ecryptfs_write_lower_page_segment(struct inode
*ecryptfs_inode,
struct page *page_for_lower,
size_t offset_in_page, size_t size)
{
- char *virt;
+ char *page_for_lower_virt;
+ char *tmp_virt;
loff_t offset;
int rc;
- offset = (page_for_lower-index PAGE_CACHE_SHIFT) + offset_in_page;
- virt = kmap(page_for_lower);
- rc = ecryptfs_write_lower(ecryptfs_inode, virt, offset, size);
- kunmap(page_for_lower);
+ tmp_virt = kmalloc(PAGE_CACHE_SIZE, GFP_KERNEL);
+ if (!tmp_virt) {
+ rc = -ENOMEM;
+ goto out;
+ }
+ offset = loff_t)page_for_lower-index) PAGE_CACHE_SHIFT)
+ + offset_in_page);
+ page_for_lower_virt = kmap_atomic(page_for_lower, KM_USER0);
+ memcpy(tmp_virt, page_for_lower_virt, PAGE_CACHE_SIZE);
+ kunmap_atomic(page_for_lower_virt, KM_USER0);
+ rc = ecryptfs_write_lower(ecryptfs_inode, tmp_virt, offset, size);
+ kfree(tmp_virt);
+out:
return rc;
}
@@ -140,8 +150,8 @@ int ecryptfs_write(struct file *ecryptfs_file, char *data,
loff_t offset,
if (num_bytes total_remaining_zeros)
num_bytes = total_remaining_zeros;
}
- ecryptfs_page = ecryptfs_get1page(ecryptfs_file,
- ecryptfs_page_idx);
+ ecryptfs_page = ecryptfs_get_locked_page(ecryptfs_file,
+ecryptfs_page_idx);
if (IS_ERR(ecryptfs_page)) {
rc = PTR_ERR(ecryptfs_page);
printk(KERN_ERR %s: Error getting page at
@@ -159,6 +169,7 @@ int ecryptfs_write(struct file *ecryptfs_file, char *data,
loff_t offset,
printk(KERN_ERR %s: Error decrypting
page; rc = [%d]\n,
__FUNCTION__, rc
Re: [Ecryptfs-devel] eCryptfs PKCS#11
On Sun, Sep 30, 2007 at 07:56:59AM +0200, Alon Bar-Lev wrote: I see you have gone a long way since I last updated [1]. I offer my help in implementing and supporting the PKCS#11 key module. Great; the more hands, the merrier. I maintain some PKCS#11 implementation in different projects, you can view some of my activity at [2]. I have maintained/hacked on OpenCryptoki on and off over the last 3 years. For instance, I brought OpenCryptoki up to the v2.20 spec last year. That does not necessarily mean that I would prefer OpenCryptoki for this specific task, but the implementation should not matter anyway. The quickest solution would be based on current OpenSSL key module and my pkcs11-helper library [3], as it already support PKCS#11 and OpenSSL engine, the only issue is that the RSA_PKCS1_OAEP_PADDING is not supported by most PKCS#11 implementation, so RSA_PKCS1_PADDING should be used. The whole point of having an API spec that it should not matter what implementation we use. I would want to make sure that we could drop in pkcs11-helper+OpenSSL, OpenCryptoki, or OpenSC interchangeably, and the PKCS#11 key module would function just the same. I can also drop OpenSSL usage to an extent of the ability to extract e, n from X.509 certificate and calculate hash int *generate_signature(). Do you prefer one over the other? I would prefer the more general solution of being able to work with a PKCS#11 interface. Also I don't really understand the *generate_key() and its relevance to key module, I don't think this should be implemented for PKCS#11, as there utilities to do exactly that. generate_key() is no longer really a call in the API, and any key generation functions are an optional feature for any given key module. For instance, take a look at ecryptfs-utils-23/src/key_mod/ecryptfs_key_mod_tspi.c; that module just sets the key gen function pointers to NULL. Unlike file based cryptography, smartcard based cryptography is dynamic, smartcard can be removed and inserted at any time. From what I understand from quick review of the source, the key module is doing private key decryption when a file is opened. If this is so, what happens when the smartcard is not available or PKCS#11 session disconnects or expires? Do we fail the system call? prompt the user? Keys are not strictly file-based, in the sense that two hard links to the same inode can have two different keys. Keys are really inode-based. Once eCryptfs has extracted (decrypted/unsealed/unwrapped/whatever) the File Encryption Key, it is in the eCryptfs inode's crypt_stat-key[] byte array in memory, where it remains until the inode is destroyed (fs/ecryptfs/super.c::ecryptfs_destroy_inode() - fs/ecryptfs/crypto.c::ecryptfs_destroy_crypt_stat()). Inodes are destroyed at the discretion of the kernel VFS; preconditions that must be met include having no process with a claim on any region of the inode's address space (via mmap's and what not). There is no mechanism in the kernel for forcing a revocation of mmap's over regions of the address space on any given event, so I think it makes the most sense to allow these categories of reads and writes to continue as usual even after the removal of the token. I do not think we really want to go down the path of removing the ECRYPTFS_KEY_VALID flag and wiping the key[] octets directly on crypt_stat's that happen to get a revoked key_sig in its keysig_list since FEK's can be protected with multiple FEKEK's; things get semantically hairy. For instance, if a file is protected by both a smartcard *and* a passphrase, and if I lose the smartcard, then I want the fallback to the passphrase to be seamless. Right now, that only happens when you open the file again in the future, but the case of already mapped memory regions will be problematic. The attempt to use the FEK on the fs/ecryptfs/mmap.c::ecryptfs_readpage()/writepage() paths will fail *for pages that happen to not be uptodate on read*, and the only way to make sure that we can't fall back on another FEKEK would be to re-run fs/ecryptfs/crypto.c::ecryptfs_read_metadata() on the persistent lower file (and this wasn't even a possibility a few weeks ago before I completed the persistent lower file patch set). Then the PageUptodate status suddenly becomes visible to the task holding an mmap (uptodate pages will still be read just fine even if there is no longer any valid key; only pages that are not uptodate that get ecryptfs_readpage() called on them would get an EIO on read attempts). That would be bad. eCryptfs might be able to carpet-bomb the entire address space's uptodate status on key revocation, but I really do not know whether this is feasible under all circumstances (or *any* circumstances, for that matter). So there is no easy answer about exactly what to do *with existing inodes* when a token is no longer available; I am leaning toward just letting existing file accesses continue until the inode gets released by the VFS in
Re: [Ecryptfs-devel] ecryptfs and readpages()
On Wed, Oct 03, 2007 at 04:13:30PM -0700, Rajouri Jammu wrote: Are there any performance advantages to doing readpages() vs readpage ? It enables readahead, so it will probably help performance. By how much, I have no idea. Mike On 10/3/07, Michael Halcrow [EMAIL PROTECTED] wrote: On Wed, Oct 03, 2007 at 02:01:05PM -0700, Rajouri Jammu wrote: It looks like ecryptfs stacked file system does not support readpages() and only supports a single page read. Is that correct? If so, is there a specific reason why it's not implemented? Nobody has requested that is be implemented before now. I can't think of any technical reason why readpages couldn't be implemented. Mike - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ eCryptfs-devel mailing list eCryptfs-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ecryptfs-devel pgpgYdGod0rY4.pgp Description: PGP signature - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/___ eCryptfs-devel mailing list eCryptfs-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ecryptfs-devel
Re: [Ecryptfs-devel] [PATCH] Build system update
On Tue, Oct 09, 2007 at 05:16:58PM -0500, Michael Halcrow wrote: On Tue, Oct 09, 2007 at 11:32:48PM +0300, Alon Bar-Lev wrote: On 10/9/07, Kent Yoder [EMAIL PROTECTED] wrote: Having both pkcs11-helper and a pure pkcs11 interface is not competing with one another. Obviously there are use cases for both. Yes it is, it splits the efforts investing in focusing on improving eCryptfs and after that, may be improving the PKCS#11 implementation. We will work on merging the key module that uses pkcs11-helper into the official ecryptfs-utils package. ecryptfs-utils-26 contains the initial version of the pkcs11-helper key module: http://downloads.sourceforge.net/ecryptfs/ecryptfs-utils-26.tar.bz2 I have made some modifications to configure.ac so that the build environment does not depend on certain library-specific m4 macros. Also, in order to maintain compatibility with current distro build processes, I have the OpenSSL key module building by default. This will probably change in future distro packages as the package metadata gets updated. Note that I have only tested the build on Gentoo 2007.1 and RHEL 5; I have not run through any tests of the key module yet, and I still need to merge Alon's latest patch. Thanks, Mike pgp1wY7iWE98n.pgp Description: PGP signature - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/___ eCryptfs-devel mailing list eCryptfs-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ecryptfs-devel
Re: [Ecryptfs-devel] [PATCH] Interactive prompt
On Sat, Oct 13, 2007 at 11:51:07PM +0200, Alon Bar-Lev wrote: On 10/13/07, Michael Halcrow [EMAIL PROTECTED] wrote: There's a timeout on receiving the reply from the daemon; see fs/ecryptfs/messaging.c::ecryptfs_wait_for_response(). That needs to be tweaked if there is going to be an interactive prompt in the middle of a syscall. Aside from that... Oh... So this what happens... How do you think it can be solved? That timeout is a kernel parameter; see the module_param() set in sf/ecryptfs/main.c. Also please notice that some crypto operations (smartcards) may take long, I know cards that takes about 5 seconds for 2048 RSA operation. We set the default to 3 seconds for now. It looks like, with this new smartcard feature, that should probably be increased to at least 10 (fs/ecryptfs/ecryptfs_kernel.h::ECRYPTFS_MAX_MSG_CTX_TTL). The eCryptfs kernel module requires that only one userspace daemon be in communication with the kernel for any given user id. The daemon Oh... I never meant to run another daemon in order to communicate with kernel... Just fork(), exec(), wait for user entry and return it to parent. Only the parent communicate with netlink socket. So long as all kernel communications are coming from the parent, then there should be no problem. If you continue to see problems after the timeout is increased, then I will need to run the code with debug statements in the kernel to find out where the problem is. Thanks, Mike signature.asc Description: Digital signature - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/___ eCryptfs-devel mailing list eCryptfs-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ecryptfs-devel
Re: [Ecryptfs-devel] [PATCH] modify eCryptfs to use the SESSION keyring
On Sun, Oct 21, 2007 at 12:00:20AM +0200, Alon Bar-Lev wrote: Except for the passphrase keys which are used directly by the kernel module, why should the other keys modules use the key store anyway? By keeping the keys in the user's persistent in-memory keyring, keys and daemon instances are entirely independent of each other. Daemons can be killed and restarted without having to go through another round of key initialization, various user applications can add and/or use the keys for their own purposes, etc. It's purely a convenience factor at this point. Well, there is an historical factor too. I think that any key not known to the kernel can be forward (as default route) to the netlink socket for further processing. Also the default encryption key if not exists on store (none passphrase), it may be forwarded to the netlink socket. The keyring was used as the common means of getting keys between kernel and userspace before the daemon and netlink socket ever existed. If RSA code ever makes it into the kernel (i.e., the MPI patchset), then some public key operations can be implemented entirely in the kernel module too. http://www.uwsg.indiana.edu/hypermail/linux/kernel/0703.2/1037.html I have said it before and I will say it again: I want to avoid introducing any dependencies on the userspace daemon that are not absolutely necessary at the moment. Frankly, I am not at all crazy about having to defer to a userspace daemon *in the middle of a syscall* anyway, and I would love to find ways to get rid of that step wherever possible. Adding dependencies on userspace components is exactly opposite of the direction I want to see eCryptfs go. The userspace components are there today only because some key management tasks absolutely require them. The kernel keyring service is simply an obvious place for *any* user application to be able to make keys available for the eCryptfs kernel module to consume later, independent of any daemon, wherever humanly possible. This allows pam_ecryptfs.so, for instance, to get the key available without having to launch a special daemon process in the middle of the user login. If the kernel keyring cannot securely provide this service, than I would start asking how to extend the kernel keyring to do that job before I would want to consider abandoning it altogether. But I really sense that your concerns relate directly to the level of *access control* that can be asserted over the secret values, regardless of the mechanism used to handle them. I agree that making the keys readable by *any* of the user's processes may be undesirable, and I understand your point about the complexity of requiring users to write SE Linux policies to use domain and type enforcement for more fine-grained access control. Outside of SE Linux policies, is there a way to make a write-only keyring, that only the eCryptfs kernel module or the userspace daemon can read the keys provided? I would prefer to only require key management apps to have to use the standard kernel keyring API to make those keys available. The model that I want to eventually achieve is this: - *Any* application can make new keys available to the eCryptfs kernel module *at any time* by only using the standard kernel keyring API. Even when there is no daemon running. - A single key object in the keyring can be used by OpenSSL, GnuPG, eCryptfs, or whatever. This is my fantasyland idea, where all crypto apps agree to use a single well-protected central point-of-access to get secret values for the life of the user's session. SE Linux can be used to achieve something like this right now, but perhaps the kernel keyring can be made to allow some kind of ACL to govern access to keys in the session keyring. - Callouts to the userspace daemon are only done for operations that absolutely require userspace components to complete. RSA is in the kernel, so standard boring public key operations are done without blasting messages out to a userspace daemon in the middle of syscalls. - Daemon instances are totally irrelevant; the user can kill his own ecryptfsd and restart it at will, and existing eCryptfs mounts will continue to operate exactly as expected, without -EIO errors suddenly being returned to other apps, and without having to go through special extra key-initialization steps. Whatever gets us closer to that model is what I tend to prefer. I am less inclined to adopt changes that take us farther from that model. Thanks, Mike signature.asc Description: Digital signature - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/___ eCryptfs-devel mailing list
[Ecryptfs-devel] [PATCH 3/3] eCryptfs: Set inode key only once per crypto operation
There is no need to keep re-setting the same key for any given
eCryptfs inode. This patch optimizes the use of the crypto API and
helps performance a bit.
Signed-off-by: Trevor Highland [EMAIL PROTECTED]
Signed-off-by: Michael Halcrow [EMAIL PROTECTED]
---
fs/ecryptfs/crypto.c |7 +--
fs/ecryptfs/ecryptfs_kernel.h |1 +
2 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/fs/ecryptfs/crypto.c b/fs/ecryptfs/crypto.c
index 4f14d4c..a0f53aa 100644
--- a/fs/ecryptfs/crypto.c
+++ b/fs/ecryptfs/crypto.c
@@ -337,8 +337,11 @@ static int encrypt_scatterlist(struct ecryptfs_crypt_stat
*crypt_stat,
}
/* Consider doing this once, when the file is opened */
mutex_lock(crypt_stat-cs_tfm_mutex);
- rc = crypto_blkcipher_setkey(crypt_stat-tfm, crypt_stat-key,
-crypt_stat-key_size);
+ if (!(crypt_stat-flags ECRYPTFS_KEY_SET)) {
+ rc = crypto_blkcipher_setkey(crypt_stat-tfm, crypt_stat-key,
+crypt_stat-key_size);
+ crypt_stat-flags |= ECRYPTFS_KEY_SET;
+ }
if (rc) {
ecryptfs_printk(KERN_ERR, Error setting key; rc = [%d]\n,
rc);
diff --git a/fs/ecryptfs/ecryptfs_kernel.h b/fs/ecryptfs/ecryptfs_kernel.h
index 78b7916..114cb86 100644
--- a/fs/ecryptfs/ecryptfs_kernel.h
+++ b/fs/ecryptfs/ecryptfs_kernel.h
@@ -234,6 +234,7 @@ struct ecryptfs_crypt_stat {
#define ECRYPTFS_KEY_VALID 0x0080
#define ECRYPTFS_METADATA_IN_XATTR 0x0100
#define ECRYPTFS_VIEW_AS_ENCRYPTED 0x0200
+#define ECRYPTFS_KEY_SET0x0400
u32 flags;
unsigned int file_version;
size_t iv_bytes;
--
1.5.0.6
-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now http://get.splunk.com/
___
eCryptfs-devel mailing list
eCryptfs-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ecryptfs-devel
[Ecryptfs-devel] [PATCH 1/3] eCryptfs: Track header bytes rather than extents
Remove internal references to header extents; just keep track of
header bytes instead. Headers can easily span multiple pages with the
recent persistent file changes.
Signed-off-by: Michael Halcrow [EMAIL PROTECTED]
---
fs/ecryptfs/crypto.c | 98 +++--
fs/ecryptfs/ecryptfs_kernel.h |3 +-
fs/ecryptfs/inode.c |8 +--
fs/ecryptfs/main.c|5 --
fs/ecryptfs/mmap.c| 21 +
5 files changed, 51 insertions(+), 84 deletions(-)
diff --git a/fs/ecryptfs/crypto.c b/fs/ecryptfs/crypto.c
index 9d70289..ca0dfea 100644
--- a/fs/ecryptfs/crypto.c
+++ b/fs/ecryptfs/crypto.c
@@ -361,8 +361,7 @@ out:
void ecryptfs_lower_offset_for_extent(loff_t *offset, loff_t extent_num,
struct ecryptfs_crypt_stat *crypt_stat)
{
- (*offset) = ((crypt_stat-extent_size
- * crypt_stat-num_header_extents_at_front)
+ (*offset) = (crypt_stat-num_header_bytes_at_front
+ (crypt_stat-extent_size * extent_num));
}
@@ -826,15 +825,13 @@ void ecryptfs_set_default_sizes(struct
ecryptfs_crypt_stat *crypt_stat)
set_extent_mask_and_shift(crypt_stat);
crypt_stat-iv_bytes = ECRYPTFS_DEFAULT_IV_BYTES;
if (crypt_stat-flags ECRYPTFS_METADATA_IN_XATTR)
- crypt_stat-num_header_extents_at_front = 0;
+ crypt_stat-num_header_bytes_at_front = 0;
else {
if (PAGE_CACHE_SIZE = ECRYPTFS_MINIMUM_HEADER_EXTENT_SIZE)
- crypt_stat-num_header_extents_at_front =
- (ECRYPTFS_MINIMUM_HEADER_EXTENT_SIZE
-/ crypt_stat-extent_size);
+ crypt_stat-num_header_bytes_at_front =
+ ECRYPTFS_MINIMUM_HEADER_EXTENT_SIZE;
else
- crypt_stat-num_header_extents_at_front =
- (PAGE_CACHE_SIZE / crypt_stat-extent_size);
+ crypt_stat-num_header_bytes_at_front = PAGE_CACHE_SIZE;
}
}
@@ -1220,7 +1217,8 @@ ecryptfs_write_header_metadata(char *virt,
header_extent_size = (u32)crypt_stat-extent_size;
num_header_extents_at_front =
- (u16)crypt_stat-num_header_extents_at_front;
+ (u16)(crypt_stat-num_header_bytes_at_front
+ / crypt_stat-extent_size);
header_extent_size = cpu_to_be32(header_extent_size);
memcpy(virt, header_extent_size, 4);
virt += 4;
@@ -1295,40 +1293,16 @@ static int ecryptfs_write_headers_virt(char *page_virt,
size_t *size,
static int
ecryptfs_write_metadata_to_contents(struct ecryptfs_crypt_stat *crypt_stat,
struct dentry *ecryptfs_dentry,
- char *page_virt)
+ char *virt)
{
- int current_header_page;
- int header_pages;
int rc;
- rc = ecryptfs_write_lower(ecryptfs_dentry-d_inode, page_virt,
- 0, PAGE_CACHE_SIZE);
- if (rc) {
+ rc = ecryptfs_write_lower(ecryptfs_dentry-d_inode, virt,
+ 0, crypt_stat-num_header_bytes_at_front);
+ if (rc)
printk(KERN_ERR %s: Error attempting to write header
information to lower file; rc = [%d]\n, __FUNCTION__,
rc);
- goto out;
- }
- header_pages = ((crypt_stat-extent_size
-* crypt_stat-num_header_extents_at_front)
- / PAGE_CACHE_SIZE);
- memset(page_virt, 0, PAGE_CACHE_SIZE);
- current_header_page = 1;
- while (current_header_page header_pages) {
- loff_t offset;
-
- offset = (((loff_t)current_header_page) PAGE_CACHE_SHIFT);
- if ((rc = ecryptfs_write_lower(ecryptfs_dentry-d_inode,
- page_virt, offset,
- PAGE_CACHE_SIZE))) {
- printk(KERN_ERR %s: Error attempting to write header
- information to lower file; rc = [%d]\n,
- __FUNCTION__, rc);
- goto out;
- }
- current_header_page++;
- }
-out:
return rc;
}
@@ -1354,15 +1328,13 @@ ecryptfs_write_metadata_to_xattr(struct dentry
*ecryptfs_dentry,
* retrieved via a prompt. Exactly what happens at this point should
* be policy-dependent.
*
- * TODO: Support header information spanning multiple pages
- *
* Returns zero on success; non-zero on error
*/
int ecryptfs_write_metadata(struct dentry *ecryptfs_dentry)
{
struct ecryptfs_crypt_stat *crypt_stat =
ecryptfs_inode_to_private(ecryptfs_dentry-d_inode)-crypt_stat;
- char *page_virt
[Ecryptfs-devel] [PATCH] eCryptfs: Release mutex on hash error path
On Mon, Oct 29, 2007 at 03:10:09PM +0900, Kazuki Ohta wrote:
When IS_ERR(desc.tfm) is true, unlocking
crypt_stat-cs_hash_tfm_mutex is forgotten.
Thanks for reporting this, Kazuki.
---
Release the crypt_stat hash mutex on allocation error. Check for error
conditions when doing crypto hash calls.
Signed-off-by: Michael Halcrow [EMAIL PROTECTED]
---
fs/ecryptfs/crypto.c | 26 ++
1 files changed, 22 insertions(+), 4 deletions(-)
diff --git a/fs/ecryptfs/crypto.c b/fs/ecryptfs/crypto.c
index a0f53aa..70f7aab 100644
--- a/fs/ecryptfs/crypto.c
+++ b/fs/ecryptfs/crypto.c
@@ -115,11 +115,29 @@ static int ecryptfs_calculate_md5(char *dst,
}
crypt_stat-hash_tfm = desc.tfm;
}
- crypto_hash_init(desc);
- crypto_hash_update(desc, sg, len);
- crypto_hash_final(desc, dst);
- mutex_unlock(crypt_stat-cs_hash_tfm_mutex);
+ rc = crypto_hash_init(desc);
+ if (rc) {
+ printk(KERN_ERR
+ %s: Error initializing crypto hash; rc = [%d]\n,
+ __FUNCTION__, rc);
+ goto out;
+ }
+ rc = crypto_hash_update(desc, sg, len);
+ if (rc) {
+ printk(KERN_ERR
+ %s: Error updating crypto hash; rc = [%d]\n,
+ __FUNCTION__, rc);
+ goto out;
+ }
+ rc = crypto_hash_final(desc, dst);
+ if (rc) {
+ printk(KERN_ERR
+ %s: Error finalizing crypto hash; rc = [%d]\n,
+ __FUNCTION__, rc);
+ goto out;
+ }
out:
+ mutex_unlock(crypt_stat-cs_hash_tfm_mutex);
return rc;
}
--
1.5.0.6
-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now http://get.splunk.com/
___
eCryptfs-devel mailing list
eCryptfs-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ecryptfs-devel
Re: [Ecryptfs-devel] [PATCH] Build system update
On Fri, Nov 09, 2007 at 09:26:32PM +0200, Alon Bar-Lev wrote: Looking at the tree... 1. You can delete config.in from the tree. Do you mean config.h.in? 2. bootstrap.sh should be only autoreconf -i -v -f, I don't think you need all the other commands. Okay. 3. What are the build-*-stamp files? Cruft; deleted. Thanks, Mike Alon. On 11/9/07, Alon Bar-Lev [EMAIL PROTECTED] wrote: On 11/7/07, Michael Halcrow [EMAIL PROTECTED] wrote: On Mon, Oct 08, 2007 at 08:48:49PM +0200, Alon Bar-Lev wrote: And BTW, where do you keep your source control? The CVS at sourceforge seems to be out of date. I have placed the source tree for ecryptfs-utils on my kernel.org account: http://git.kernel.org/?p=linux/kernel/git/mhalcrow/ecryptfs-utils.git;a=summary Mike Great! But... $ git clone http://www.kernel.org/pub/scm/linux/kernel/git/mhalcrow/ecryptfs-utils.git Initialized empty Git repository in /home/alonbl/my/Development/ecryptfs-utils/ecryptfs-utils/.git/ Cannot get remote repository information. Perhaps git-update-server-info needs to be run there? pgpBkAlrwNiMW.pgp Description: PGP signature - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/___ eCryptfs-devel mailing list eCryptfs-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ecryptfs-devel
Re: [Ecryptfs-devel] [PATCH] Build system update
On Fri, Nov 09, 2007 at 11:38:37PM +0200, Alon Bar-Lev wrote: Also very strange... I cannot access the repository using git protocol. And when I use http, I don't see your recent changes. Hmmm? It looks like it takes a little while for the external GIT view to sync up with the master GIT tree on master.kernel.org (where I do my updates via ssh). Mike pgp8rDX3SZmCz.pgp Description: PGP signature - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/___ eCryptfs-devel mailing list eCryptfs-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ecryptfs-devel
Re: [Ecryptfs-devel] eCryptfs Key Module interface
On Sat, Nov 10, 2007 at 01:05:55AM +0200, Alon Bar-Lev wrote: I guess we are back on business? Can you please address these point? Your suggestions make sense. I don't have a lot of time over the next 4 weeks to work on anything but critical bugfixes (kernel oops/segfault type stuff). If someone wants to spend the time to make these modifications and send patches along, I will review and merge them. 1. Introduce statefull mode. So long as it is not a global state (i.e., it is referenced with a handle that gets created by the key module and passed in on future calls), I have no problem with that. I would like to keep the generic calls into key module (i.e., ones that do not involve any sort of session handle or what not) to remain reentrant. 2. Allow the key module to report that a key is unusable. Is the idea to prevent attempts to call encrypt/decrypt repeatedly? In this case, we probably just need the proper return codes, along with perhaps some annotation on the key in the user keyring for future calls. 3. Key module context parameters Allow key module specific parameter that are not related to a specific key, this will allow to specify some module wide options. It should be read from some configuration file and forwarded to the key module during initialization. I am inclined to just let each key module handle its own configuration file in this case rather than futher complicate the existing configuration file parsing code. 4. [Not directly related] Pluggable Random Generator If you are talking about the per-file key generated in the kernel, then this is more a kernel-level change than anything we should do in userspace. The kernel already supports swapping out the random number generator used for calls for random numbers via its own API (HW_RANDOM build option). Mike pgpozYedqTPBN.pgp Description: PGP signature - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/___ eCryptfs-devel mailing list eCryptfs-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ecryptfs-devel
Re: [Ecryptfs-devel] [PATCH] Build - locate gpgme better
On Tue, Nov 20, 2007 at 08:06:12PM +0200, Alon Bar-Lev wrote:
Use gpgme-config.
Merged.
---
diff --git a/configure.ac b/configure.ac
index 6778105..ba6484d 100644
--- a/configure.ac
+++ b/configure.ac
@@ -93,6 +93,13 @@ AC_ARG_ENABLE(
)
AC_ARG_WITH(
+ [gpgme-prefix],
+ [AC_HELP_STRING([--with-gpgme-prefix=PATH], [Specify the directory
where gpgme install, default /usr])],
+ ,
+ [with_gpgme_prefix=/usr]
+)
+
+AC_ARG_WITH(
[pamdir],
[AC_HELP_STRING([--with-pamdir=PATH], [Specify the directory where PAM
modules are stored])],
[pamdir=${withval}],
@@ -233,15 +240,13 @@ if test ${enable_tspi} = yes ; then
fi
if test ${enable_gpg} = yes ; then
- if test -z ${GPGME_LIBS}; then
- AC_ARG_VAR([GPGME_CFLAGS], [C compiler flags for gpg])
- AC_ARG_VAR([GPGME_LIBS], [linker flags for gpg])
- AC_CHECK_LIB(
- [gpgme],
- [gpgme_new],
- [GPGME_LIBS=-lgpgme],
- [AC_MSG_ERROR([Cannot find gpgme])]
- )
+ AC_MSG_CHECKING([for gpgme])
+ if ! test -x ${with_gpgme_prefix}/bin/gpgme-config; then
+ AC_MSG_ERROR([Cannot locate gpgme])
+ else
+ AC_MSG_RESULT([found])
+ GPGME_CFLAGS=`\${with_gpgme_prefix}/bin/gpgme-config\
--cflags`
+ GPGME_LIBS=`\${with_gpgme_prefix}/bin/gpgme-config\ --libs`
fi
fi
@@ -280,6 +285,8 @@ AC_SUBST([pamlibdir])
AC_SUBST([pkgconfigdir])
AC_SUBST([rootsbindir])
AC_SUBST([ecryptfskeymoddir])
+AC_SUBST([GPGME_CFLAGS])
+AC_SUBST([GPGME_LIBS])
AM_CONDITIONAL([BUILD_OPENSSL], [test ${enable_openssl} = yes])
AM_CONDITIONAL([BUILD_PKCS11_HELPER], [test ${enable_pkcs11_helper} =
yes])
AM_CONDITIONAL([BUILD_TSPI], [test ${enable_tspi} = yes])
--
.___.
Michael A. Halcrow
Security Software Engineer, IBM Linux Technology Center
GnuPG Fingerprint: 419C 5B1E 948A FA73 A54C 20F5 DB40 8531 6DCA 8769
Most people aren't thought about after they're gone. I wonder where
Mike got the plutonium is better than what most get.
signature.asc
Description: Digital signature
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___
eCryptfs-devel mailing list
eCryptfs-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ecryptfs-devel
Re: [Ecryptfs-devel] [PATCH] Detect gtk+ better
On Sat, Dec 08, 2007 at 12:05:04AM +0200, Alon Bar-Lev wrote: On Dec 8, 2007 12:00 AM, Michael Halcrow [EMAIL PROTECTED] wrote: On Fri, Dec 07, 2007 at 09:20:45AM +0200, Alon Bar-Lev wrote: The changes are in your repository but not in the public one... Strange... 5 days and it was not updated. What do you mean by your repository and the public one? I see the commit at kernel.org, but when I pull I get no update. It's working fine for me on a fresh clone. Maybe you need to try adding a master:master at the end of your pull command. Mike pgpwlBiCavfXV.pgp Description: PGP signature - SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php___ eCryptfs-devel mailing list eCryptfs-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ecryptfs-devel
Re: [Ecryptfs-devel] [PATCH] Detect gtk+ better
On Fri, Dec 07, 2007 at 09:20:45AM +0200, Alon Bar-Lev wrote: The changes are in your repository but not in the public one... Strange... 5 days and it was not updated. What do you mean by your repository and the public one? On 12/4/07, Alon Bar-Lev [EMAIL PROTECTED] wrote: On 12/4/07, Michael Halcrow [EMAIL PROTECTED] wrote: Also note that Karsten Hopp [EMAIL PROTECTED] recently fixed a bug that kept ecryptfs-utils from installing correctly in ia64: Please CC me on build modifications... I will be happy to review. Also please push updates... This was taken from the old build system... But if it had troubles I think the attached one is better. Regards, Alon. - SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ eCryptfs-devel mailing list eCryptfs-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ecryptfs-devel pgp37DcUzri6P.pgp Description: PGP signature - SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php___ eCryptfs-devel mailing list eCryptfs-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ecryptfs-devel
Re: [Ecryptfs-devel] fix version support to work with decision graph.
On Mon, Dec 31, 2007 at 01:15:36AM -0600, Trevor Highland wrote:
When configuring mount options eCryptfs is not prompting for
passthrough support. This patch fixes it.
In addition, all mount options directed at eCryptfs should be prefixed
with ecryptfs_. The README is already updated with this info. I
committed a modified version of this patch to GIT.
Thanks,
Mike
From 153d8c23a8ce3471f2fde0b08e6b0c1bd5e03726 Mon Sep 17 00:00:00 2001
From: Trevor Highland [EMAIL PROTECTED](none)
Date: Mon, 31 Dec 2007 01:12:21 -0600
Subject: [PATCH] fix version support to work with decision graph
---
src/libecryptfs/module_mgr.c | 20 ++--
1 files changed, 18 insertions(+), 2 deletions(-)
diff --git a/src/libecryptfs/module_mgr.c b/src/libecryptfs/module_mgr.c
index 89e82da..47e69bb 100644
--- a/src/libecryptfs/module_mgr.c
+++ b/src/libecryptfs/module_mgr.c
@@ -136,6 +136,22 @@ static int get_encrypted_passthrough(struct ecryptfs_ctx
*ctx,
return 0;
}
+static struct param_node ecryptfs_version_support_node = {
+ .num_mnt_opt_names = 1,
+ .mnt_opt_names = {end},
+ .prompt = end,
+ .val_type = VAL_STR,
+ .val = NULL,
+ .display_opts = NULL,
+ .default_val = NULL,
+ .flags = ECRYPTFS_PARAM_FLAG_NO_VALUE,
+ .num_transitions = 1,
+ .tl = {{.val = default,
+ .pretty_val = default,
+ .next_token = NULL,
+ .trans_func = NULL}}
+};
+
static struct param_node end_param_node = {
.num_mnt_opt_names = 1,
.mnt_opt_names = {end},
@@ -296,7 +312,7 @@ static int init_ecryptfs_key_bytes_param_node(char
*cipher_name)
}
rc = 0;
}
- tn-next_token = end_param_node;
+ tn-next_token = ecryptfs_version_support_node;
tn-trans_func = tf_ecryptfs_key_bytes;
ecryptfs_key_bytes_param_node.num_transitions++;
}
@@ -506,7 +522,7 @@ static int
fill_in_decision_graph_based_on_version_support(struct param_node *root,
uint32_t version)
{
- struct param_node *last_param_node = ecryptfs_key_bytes_param_node;
+ struct param_node *last_param_node = end_param_node1;
int rc;
ecryptfs_set_exit_param_on_graph(root, another_key_param_node);
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
eCryptfs-devel mailing list
eCryptfs-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ecryptfs-devel
pgp9pycn0r2gA.pgp
Description: PGP signature
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___
eCryptfs-devel mailing list
eCryptfs-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ecryptfs-devel
Re: [Ecryptfs-devel] Bugs?
On Fri, Feb 29, 2008 at 12:28:01PM +0100, Benedikt Driessen wrote: I'd like to begin with two issues which seem to affect only the pkcs11_helper-module. 1. Entering a PIN via ssh-askpass (or equivalent) does NOT work, the kernel-userspace communication seems to be disrupted by the fork() in daemon.c::prompt_callback(). (I already saw this issue floating around some time ago..). And yes, I set the timeout value to 10. 2. None of the parameters in ~/.ecryptfsrc.pkcs11 for pkcs11-provider (e.g. name=xy,library=xy..) seems to be optional, in case the line beginning with pkcs11-provider does not end with private-mask=xy, the provider library will not be loaded and eCryptfs will fail with meaningless messages (at least in non-debug mode). Alon is probably the best person right now to respond regarding issues with the pkcs11-helper key module. The following issues seems to be a problem of eCryptfs itself: 3. When using kernel 2.6.24 and loading the ecryptfs module, everything is fine. When I start the ecryptfsd the system crashes (I'm starting ecryptfsd as root). This is a known bug in eCryptfs+netlink in 2.6.24. I am working on a replacement mechanism for communicating with userspace via procfs instead. In the meantime, some debug work is needed to find out why netlink support in eCryptfs broke between 2.6.23 and 2.6.24. 4. ! Data gets corrupted when I do something like the following (using the pkcs11_helper key module..) ! $ mkdir secret $ mount -t ecryptfs secret secret $ echo abc secret/test $ cat secret/test abc $ umount secret $ mount -t ecryptfs secret secret $ echo def secret/test $ cat secret/test def Yup; this is a bug all right. I'm surprised it hasn't hit anyone's radar until now. I'll look into it. Mike pgpFbZIIWLHug.pgp Description: PGP signature - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___ eCryptfs-devel mailing list eCryptfs-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ecryptfs-devel
Re: [Ecryptfs-devel] [PATCH] libtool modules cleanups
On Sun, Mar 09, 2008 at 10:45:28PM +0200, Alon Bar-Lev wrote: This is a cleanup for libtool statements. It looks like if you define --module -avoid-version it does what you want... :) Thanks; patch merged. --- diff --git a/src/key_mod/Makefile.am b/src/key_mod/Makefile.am index 50e3674..c282d38 100644 --- a/src/key_mod/Makefile.am +++ b/src/key_mod/Makefile.am @@ -14,31 +14,32 @@ ecryptfskeymod_LTLIBRARIES+=libecryptfs_key_mod_gpg.la endif libecryptfs_key_mod_openssl_la_SOURCES = ecryptfs_key_mod_openssl.c -libecryptfs_key_mod_openssl_la_LDFLAGS = $(OPENSSL_LIBS) libecryptfs_key_mod_openssl_la_CFLAGS = $(AM_CFLAGS) $(OPENSSL_CFLAGS) +libecryptfs_key_mod_openssl_la_LIBADD = $(OPENSSL_LIBS) +libecryptfs_key_mod_openssl_la_LDFLAGS = $(AM_LDFLAGS) -module -avoid-version libecryptfs_key_mod_pkcs11_helper_la_SOURCES = ecryptfs_key_mod_pkcs11_helper.c libecryptfs_key_mod_pkcs11_helper_la_CFLAGS = $(AM_CFLAGS) $(PKCS11_HELPER_CFLAGS) $(OPENSSL_CFLAGS) libecryptfs_key_mod_pkcs11_helper_la_LIBADD = $(PKCS11_HELPER_LIBS) $(OPENSSL_LIBS) +libecryptfs_key_mod_pkcs11_helper_la_LDFLAGS = $(AM_LDFLAGS) -module -avoid-version libecryptfs_key_mod_tspi_la_SOURCES = ecryptfs_key_mod_tspi.c libecryptfs_key_mod_tspi_la_CFLAGS = $(AM_CFLAGS) $(TSPI_CFLAGS) libecryptfs_key_mod_tspi_la_LIBADD = $(TSPI_LIBS) +libecryptfs_key_mod_tspi_la_LDFLAGS = $(AM_LDFLAGS) -module -avoid-version libecryptfs_key_mod_gpg_la_SOURCES = ecryptfs_key_mod_gpg.c libecryptfs_key_mod_gpg_la_CFLAGS = $(AM_CFLAGS) $(GPGME_CFLAGS) libecryptfs_key_mod_gpg_la_LIBADD = $(GPGME_LIBS) +libecryptfs_key_mod_gpg_la_LDFLAGS = $(AM_LDFLAGS) -module -avoid-version libecryptfs_key_mod_passphrase_la_SOURCES = ecryptfs_key_mod_passphrase.c libecryptfs_key_mod_passphrase_la_CFLAGS = $(AM_CFLAGS) $(LIBGCRYPT_CFLAGS) libecryptfs_key_mod_passphrase_la_LIBADD = $(LIBGCRYPT_LIBS) +libecryptfs_key_mod_passphrase_la_LDFLAGS = $(AM_LDFLAGS) -module -avoid-version install-data-hook: for f in `echo $(ecryptfskeymod_LTLIBRARIES) | $(SED) 's/\.la//g'`; do \ - rm -fr \ - $(DESTDIR)$(ecryptfskeymoddir)/$$f.la \ - $(DESTDIR)$(ecryptfskeymoddir)/$$f.a \ - $(DESTDIR)$(ecryptfskeymoddir)/$$f.so \ - $(DESTDIR)$(ecryptfskeymoddir)/$$f.so.0; \ - mv -f $(DESTDIR)$(ecryptfskeymoddir)/$$f.so.0.0.0 $(DESTDIR)$(ecryptfskeymoddir)/$$f.so ; \ + rm -f $(DESTDIR)$(ecryptfskeymoddir)/$$f.la; \ + rm -f $(DESTDIR)$(ecryptfskeymoddir)/$$f.a; \ done diff --git a/src/pam_ecryptfs/Makefile.am b/src/pam_ecryptfs/Makefile.am index 0540c5a..7216ea8 100644 --- a/src/pam_ecryptfs/Makefile.am +++ b/src/pam_ecryptfs/Makefile.am @@ -2,17 +2,11 @@ if BUILD_PAM pam_LTLIBRARIES = libpam_ecryptfs.la install-data-hook: - mv -f $(DESTDIR)$(pamdir)/libpam_ecryptfs.so.0.0.0 $(DESTDIR)$(pamdir)/pam_ecryptfs.so - rm -fr \ - $(DESTDIR)$(pamdir)/libpam_ecryptfs.so.0 \ - $(DESTDIR)$(pamdir)/libpam_ecryptfs.so \ - $(DESTDIR)$(pamdir)/libpam_ecryptfs.la \ - $(DESTDIR)$(pamdir)/libpam_ecryptfs.a + rm -f $(DESTDIR)$(pamdir)/libpam_ecryptfs.la + rm -f $(DESTDIR)$(pamdir)/libpam_ecryptfs.a endif -# force libtool to install us -libdir=$(pamlibdir) - libpam_ecryptfs_la_SOURCES = pam_ecryptfs.c libpam_ecryptfs_la_CFLAGS = $(AM_CFLAGS) $(LIBGCRYPT_CFLAGS) libpam_ecryptfs_la_LIBADD = $(top_srcdir)/src/libecryptfs/libecryptfs.la $(PAM_LIBS) $(LIBGCRYPT_LIBS) +libpam_ecryptfs_la_LDFLAGS = $(AM_LDFLAGS) -module -avoid-version pgpEiTNtytxoe.pgp Description: PGP signature - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___ eCryptfs-devel mailing list eCryptfs-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ecryptfs-devel
Re: [Ecryptfs-devel] ecryptfs and automount
On Wed, Apr 02, 2008 at 06:56:22PM -0700, Rajouri Jammu wrote: How can I setup ecryptfs to mount on the automounted mnt points via automount? It depends on exactly how you want to provide the key, but this guide gives a starting point: http://ecryptfs.sourceforge.net/ecryptfs-pam-doc.txt signature.asc Description: Digital signature - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace___ eCryptfs-devel mailing list eCryptfs-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ecryptfs-devel
Re: [Ecryptfs-devel] Fixed?!
On Mon, Apr 07, 2008 at 03:31:53PM +0200, Benedikt Driessen wrote: Starting ecryptfsd (the one from the git-repository) with both patches applied to 2.6.24 results in a kernel-oops (which is an improvement, at least not the whole system crashes..). In that case, I would bet that you still get an oops even without the NFS patch applied. These two patches do not touch the same regions of code, and there is no reason for the NFS patch to affect the procfs patch. Please post the contents of the oops from your system log (along with any other interesting error messages). Thanks, Mike signature.asc Description: Digital signature - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Register now and save $200. Hurry, offer ends at 11:59 p.m., Monday, April 7! Use priority code J8TLD2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone___ eCryptfs-devel mailing list eCryptfs-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ecryptfs-devel
Re: [Ecryptfs-devel] Fixed?!
On Mon, Apr 07, 2008 at 03:31:53PM +0200, Benedikt Driessen wrote: Starting ecryptfsd (the one from the git-repository) with both patches applied to 2.6.24 results in a kernel-oops (which is an improvement, at least not the whole system crashes..). One of these days I am going to learn to test even my most trivial changes. I added a try_module_get() at the last minute to prevent the module from being unloaded while a daemon has its handle open. I assumed non-zero was an error code for that function call; it turns out that zero is the error condition. That flub is fixed in this version of the patch: http://downloads.sourceforge.net/ecryptfs/ecryptfs-procfs-kernel-20080407.txt Mike signature.asc Description: Digital signature - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Register now and save $200. Hurry, offer ends at 11:59 p.m., Monday, April 7! Use priority code J8TLD2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone___ eCryptfs-devel mailing list eCryptfs-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ecryptfs-devel
Re: [Ecryptfs-devel] exporting ecryptfs mnt over NFS
On Tue, Apr 08, 2008 at 10:07:45PM -0700, Rajouri Jammu wrote: Is there a way to export an ecryptfs mount point over NFS?I tried doing it but it didn't work. eCryptfs cannot be exported via NFS because eCryptfs does not currently implement export_ops. Mike signature.asc Description: Digital signature - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone___ eCryptfs-devel mailing list eCryptfs-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ecryptfs-devel
Re: [Ecryptfs-devel] exporting ecryptfs mnt over NFS
On Wed, Apr 09, 2008 at 10:59:17AM -0700, Rajouri Jammu wrote: Are there plans to implement export_ops? I would like to see export_ops implemented, but I probably will not get around to it until I am done with the procfs (which is probably going to morph into dev/misc, by the way) and filename crypto code. Mike signature.asc Description: Digital signature - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone___ eCryptfs-devel mailing list eCryptfs-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ecryptfs-devel
Re: [Ecryptfs-devel] [PATCH 1/2] eCryptfs: Introduce device handle for userspace daemon communications
On Tue, Apr 15, 2008 at 02:04:53PM -0700, Andrew Morton wrote: On Tue, 15 Apr 2008 15:23:13 -0500 Michael Halcrow [EMAIL PROTECTED] wrote: Functions to facilitate reading and writing to the eCryptfs miscellaneous device handle. This will replace the netlink interface as the preferred mechanism for communicating with the userspace eCryptfs daemon. Each user has his own daemon, which registers itself by opening the eCryptfs device handle. Only one daemon per euid may be registered at any given time. The eCryptfs module sends a message to a daemon by adding its message to the daemon's outgoing message queue. The daemon reads the device handle to get the oldest message off the queue. Incoming messages from the userspace daemon are immediately handled. If the message is a response, then the corresponding process that is blocked waiting for the response is awakened. This is a drastic change, but the changelog doesn't tell us why it is being made! This resurrects the question from 2006: On Thu, Aug 24, 2006 at 08:54:19PM -0700, Andrew Morton wrote: - _why_ does it use netlink? I responded: Netlink provides the transport mechanism that would minimize the complexity of the implementation, given that we can have multiple daemons (one per user). A regular device file was my real preference from the get-go, but I went with netlink at the time because I thought it would be less complex for managing send queues (i.e., just do a unicast and move on). It turns out that we do not really get that much complexity reduction with netlink, and netlink is more heavyweight than a device handle. In addition, the netlink interface to eCryptfs has been broken since 2.6.24. I am assuming this is a bug in how eCryptfs uses netlink, since the other in-kernel users of netlink do not seem to be having any problems. I have had one report of a user successfully using eCryptfs with netlink on 2.6.24, but for my own systems, when starting the userspace daemon, the initial helo message sent to the eCryptfs kernel module results in an oops right off the bat. I spent some time looking at it, but I have not yet found the cause. The netlink interface breaking gave me the motivation to just finish my patch to migrate to a regular device handle. If I cannot find out soon why the netlink interface in eCryptfs broke, I am likely to just send a patch to disable it in 2.6.24 and 2.6.25. I would like the device handle to be the preferred means of communicating with the userspace daemon from 2.6.26 on forward. Mike - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ eCryptfs-devel mailing list eCryptfs-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ecryptfs-devel
[Ecryptfs-devel] [PATCH] eCryptfs: Make key module subsystem respect namespaces
On Tue, Apr 15, 2008 at 04:34:02PM -0500, Serge E. Hallyn wrote:
Quoting Andrew Morton ([EMAIL PROTECTED]):
On Tue, 15 Apr 2008 15:23:13 -0500
Michael Halcrow [EMAIL PROTECTED] wrote:
...
+ rc = ecryptfs_find_daemon_by_euid(daemon, current-euid);
+ if (daemon-pid != current-pid) {
+ rc = ecryptfs_find_daemon_by_euid(daemon, current-euid);
+ BUG_ON(current-euid != daemon-euid);
+ BUG_ON(current-pid != daemon-pid);
This code uses pids and uids all over the place. Will it operate
correctly in a containerised environment?
Thanks Andrew.
Mike, the pid_t definately needs to be replaced with a struct pid.
As for the euid, it'd be best if you also compared the user_namespace *
to make sure we support one ecryptfs deamon per user namespace.
Make eCryptfs key module subsystem respect namespaces.
Since I will be removing the netlink interface in a future patch, I
just made changes to the netlink.c code so that it will not break the
build. With my recent patches, the kernel module currently defaults to
the device handle interface rather than the netlink interface.
Signed-off-by: Michael Halcrow [EMAIL PROTECTED]
---
fs/ecryptfs/ecryptfs_kernel.h | 25 +-
fs/ecryptfs/messaging.c | 71 +---
fs/ecryptfs/miscdev.c | 68 +--
fs/ecryptfs/netlink.c | 25 +-
4 files changed, 126 insertions(+), 63 deletions(-)
diff --git a/fs/ecryptfs/ecryptfs_kernel.h b/fs/ecryptfs/ecryptfs_kernel.h
index 88b85f7..dc11431 100644
--- a/fs/ecryptfs/ecryptfs_kernel.h
+++ b/fs/ecryptfs/ecryptfs_kernel.h
@@ -34,6 +34,7 @@
#include linux/namei.h
#include linux/scatterlist.h
#include linux/hash.h
+#include linux/nsproxy.h
/* Version verification for shared data structures w/ userspace */
#define ECRYPTFS_VERSION_MAJOR 0x00
@@ -410,8 +411,9 @@ struct ecryptfs_daemon {
#define ECRYPTFS_DAEMON_MISCDEV_OPEN 0x0008
u32 flags;
u32 num_queued_msg_ctx;
- pid_t pid;
+ struct pid *pid;
uid_t euid;
+ struct user_namespace *user_ns;
struct task_struct *task;
struct mutex mux;
struct list_head msg_ctx_out_queue;
@@ -610,10 +612,13 @@ int
ecryptfs_setxattr(struct dentry *dentry, const char *name, const void *value,
size_t size, int flags);
int ecryptfs_read_xattr_region(char *page_virt, struct inode *ecryptfs_inode);
-int ecryptfs_process_helo(unsigned int transport, uid_t uid, pid_t pid);
-int ecryptfs_process_quit(uid_t uid, pid_t pid);
-int ecryptfs_process_response(struct ecryptfs_message *msg, uid_t uid,
- pid_t pid, u32 seq);
+int ecryptfs_process_helo(unsigned int transport, uid_t euid,
+ struct user_namespace *user_ns, struct pid *pid);
+int ecryptfs_process_quit(uid_t euid, struct user_namespace *user_ns,
+ struct pid *pid);
+int ecryptfs_process_response(struct ecryptfs_message *msg, uid_t euid,
+ struct user_namespace *user_ns, struct pid *pid,
+ u32 seq);
int ecryptfs_send_message(unsigned int transport, char *data, int data_len,
struct ecryptfs_msg_ctx **msg_ctx);
int ecryptfs_wait_for_response(struct ecryptfs_msg_ctx *msg_ctx,
@@ -623,13 +628,13 @@ void ecryptfs_release_messaging(unsigned int transport);
int ecryptfs_send_netlink(char *data, int data_len,
struct ecryptfs_msg_ctx *msg_ctx, u8 msg_type,
- u16 msg_flags, pid_t daemon_pid);
+ u16 msg_flags, struct pid *daemon_pid);
int ecryptfs_init_netlink(void);
void ecryptfs_release_netlink(void);
int ecryptfs_send_connector(char *data, int data_len,
struct ecryptfs_msg_ctx *msg_ctx, u8 msg_type,
- u16 msg_flags, pid_t daemon_pid);
+ u16 msg_flags, struct pid *daemon_pid);
int ecryptfs_init_connector(void);
void ecryptfs_release_connector(void);
void
@@ -672,7 +677,8 @@ int ecryptfs_read_lower_page_segment(struct page
*page_for_ecryptfs,
struct inode *ecryptfs_inode);
struct page *ecryptfs_get_locked_page(struct file *file, loff_t index);
int ecryptfs_exorcise_daemon(struct ecryptfs_daemon *daemon);
-int ecryptfs_find_daemon_by_euid(struct ecryptfs_daemon **daemon, uid_t euid);
+int ecryptfs_find_daemon_by_euid(struct ecryptfs_daemon **daemon, uid_t euid,
+struct user_namespace *user_ns);
int ecryptfs_parse_packet_length(unsigned char *data, size_t *size,
size_t *length_size);
int ecryptfs_write_packet_length(char *dest, size_t size,
@@ -684,6 +690,7 @@ int ecryptfs_send_miscdev(char *data, size_t data_size,
u16 msg_flags, struct ecryptfs_daemon *daemon);
void
[Ecryptfs-devel] [PATCH] eCryptfs: Remove obsolete netlink interface to daemon
Remove the obsolete and buggy netlink interface to the userspace
daemon.
Signed-off-by: Michael Halcrow [EMAIL PROTECTED]
---
fs/ecryptfs/Makefile |2 +-
fs/ecryptfs/ecryptfs_kernel.h | 12 --
fs/ecryptfs/main.c| 15 +--
fs/ecryptfs/messaging.c | 31 ++
fs/ecryptfs/netlink.c | 249 -
5 files changed, 17 insertions(+), 292 deletions(-)
delete mode 100644 fs/ecryptfs/netlink.c
diff --git a/fs/ecryptfs/Makefile b/fs/ecryptfs/Makefile
index 1e34a7f..aa22276 100644
--- a/fs/ecryptfs/Makefile
+++ b/fs/ecryptfs/Makefile
@@ -4,4 +4,4 @@
obj-$(CONFIG_ECRYPT_FS) += ecryptfs.o
-ecryptfs-objs := dentry.o file.o inode.o main.o super.o mmap.o read_write.o
crypto.o keystore.o messaging.o netlink.o miscdev.o debug.o
+ecryptfs-objs := dentry.o file.o inode.o main.o super.o mmap.o read_write.o
crypto.o keystore.o messaging.o miscdev.o debug.o
diff --git a/fs/ecryptfs/ecryptfs_kernel.h b/fs/ecryptfs/ecryptfs_kernel.h
index dc11431..661f202 100644
--- a/fs/ecryptfs/ecryptfs_kernel.h
+++ b/fs/ecryptfs/ecryptfs_kernel.h
@@ -625,18 +625,6 @@ int ecryptfs_wait_for_response(struct ecryptfs_msg_ctx
*msg_ctx,
struct ecryptfs_message **emsg);
int ecryptfs_init_messaging(unsigned int transport);
void ecryptfs_release_messaging(unsigned int transport);
-
-int ecryptfs_send_netlink(char *data, int data_len,
- struct ecryptfs_msg_ctx *msg_ctx, u8 msg_type,
- u16 msg_flags, struct pid *daemon_pid);
-int ecryptfs_init_netlink(void);
-void ecryptfs_release_netlink(void);
-
-int ecryptfs_send_connector(char *data, int data_len,
- struct ecryptfs_msg_ctx *msg_ctx, u8 msg_type,
- u16 msg_flags, struct pid *daemon_pid);
-int ecryptfs_init_connector(void);
-void ecryptfs_release_connector(void);
void
ecryptfs_write_header_metadata(char *virt,
struct ecryptfs_crypt_stat *crypt_stat,
diff --git a/fs/ecryptfs/main.c b/fs/ecryptfs/main.c
index d25ac95..55fee42 100644
--- a/fs/ecryptfs/main.c
+++ b/fs/ecryptfs/main.c
@@ -30,7 +30,6 @@
#include linux/namei.h
#include linux/skbuff.h
#include linux/crypto.h
-#include linux/netlink.h
#include linux/mount.h
#include linux/pagemap.h
#include linux/key.h
@@ -49,8 +48,7 @@ MODULE_PARM_DESC(ecryptfs_verbosity,
0, which is Quiet));
/**
- * Module parameter that defines the number of netlink message buffer
- * elements
+ * Module parameter that defines the number of message buffer elements
*/
unsigned int ecryptfs_message_buf_len = ECRYPTFS_DEFAULT_MSG_CTX_ELEMS;
@@ -59,10 +57,8 @@ MODULE_PARM_DESC(ecryptfs_message_buf_len,
Number of message buffer elements);
/**
- * Module parameter that defines the maximum guaranteed amount of time to wait
- * for a response through netlink. The actual sleep time will be, more than
- * likely, a small amount greater than this specified value, but only less if
- * the netlink message successfully arrives.
+ * Module parameter that defines the maximum guaranteed amount of time
+ * to wait for a response from the userspace daemon.
*/
signed long ecryptfs_message_wait_timeout = ECRYPTFS_MAX_MSG_CTX_TTL / HZ;
@@ -797,8 +793,9 @@ static int __init ecryptfs_init(void)
}
rc = ecryptfs_init_messaging(ecryptfs_transport);
if (rc) {
- ecryptfs_printk(KERN_ERR, Failure occured while attempting to
- initialize the eCryptfs netlink socket\n);
+ printk(KERN_ERR %s: Failure occured while attempting to
+ initialize the eCryptfs daemon messaging subsystem;
+ rc = [%d]\n, __func__, rc);
goto out_do_sysfs_unregistration;
}
rc = ecryptfs_init_crypto();
diff --git a/fs/ecryptfs/messaging.c b/fs/ecryptfs/messaging.c
index fad161b..be1622d 100644
--- a/fs/ecryptfs/messaging.c
+++ b/fs/ecryptfs/messaging.c
@@ -155,16 +155,13 @@ static int ecryptfs_send_raw_message(unsigned int
transport, u8 msg_type,
int rc;
switch(transport) {
- case ECRYPTFS_TRANSPORT_NETLINK:
- rc = ecryptfs_send_netlink(NULL, 0, NULL, msg_type, 0,
- daemon-pid);
- break;
case ECRYPTFS_TRANSPORT_MISCDEV:
rc = ecryptfs_send_message_locked(transport, NULL, 0, msg_type,
msg_ctx);
if (rc) {
printk(KERN_ERR %s: Error whilst attempting to send
- message via procfs; rc = [%d]\n, __func__, rc);
+ message via device handle; rc = [%d]\n,
+ __func__, rc);
goto out;
}
/* Raw messages are logically context-free (e.g
[Ecryptfs-devel] [PATCH] eCryptfs: Fix refs to pid and user_ns
On Thu, Apr 17, 2008 at 10:34:06AM -0500, Serge E. Hallyn wrote:
Quoting Michael Halcrow ([EMAIL PROTECTED]):
@@ -206,6 +210,7 @@ ecryptfs_spawn_daemon(struct ecryptfs_daemon **daemon,
uid_t euid, pid_t pid)
goto out;
}
(*daemon)-euid = euid;
+ (*daemon)-user_ns = user_ns;
(*daemon)-pid = pid;
You'll want to do a get_pid() here, no?
And get_user_ns().
It's not because you particulary need them to stick around, but just
to ensure no wraparound causes another daemon with the same struct
pid or user_namespace to be spawned. Pretty gosh-darned unlikely,
but still...
...
@@ -372,12 +383,24 @@ int ecryptfs_process_response(struct ecryptfs_message
*msg, uid_t euid,
msg_ctx = ecryptfs_msg_ctx_arr[msg-index];
mutex_lock(msg_ctx-mux);
mutex_lock(ecryptfs_daemon_hash_mux);
- rc = ecryptfs_find_daemon_by_euid(daemon, msg_ctx-task-euid);
+ rcu_read_lock();
+ nsproxy = task_nsproxy(msg_ctx-task);
+ if (nsproxy == NULL) {
+ rc = -EBADMSG;
+ printk(KERN_ERR %s: Receiving process is a zombie. Dropping
+ message.\n, __func__);
+ rcu_read_unlock();
+ mutex_unlock(ecryptfs_daemon_hash_mux);
+ goto wake_up;
+ }
+ rc = ecryptfs_find_daemon_by_euid(daemon, msg_ctx-task-euid,
+ nsproxy-user_ns);
+ rcu_read_unlock();
mutex_unlock(ecryptfs_daemon_hash_mux);
if (rc) {
rc = -EBADMSG;
printk(KERN_WARNING %s: User [%d] received a
- message response from process [%d] but does
+ message response from process [0x%p] but does
not have a registered daemon\n, __func__,
msg_ctx-task-euid, pid);
goto wake_up;
@@ -389,10 +412,17 @@ int ecryptfs_process_response(struct ecryptfs_message
*msg, uid_t euid,
euid, msg_ctx-task-euid);
goto unlock;
}
+ if (nsproxy-user_ns != user_ns) {
Since you didn't grab a ref to the nsproxy, it's possible that it
will have been freed before this, right? So you probably just want
to grab a copy of nsproxy-user_ns while under the rcu_read_lock,
where you can be sure it's still around.
Have eCryptfs properly reference the pid and user_ns objects. Copy
user_ns out of nsproxy in case nsproxy goes away after we drop the
lock.
Signed-off-by: Michael Halcrow [EMAIL PROTECTED]
---
fs/ecryptfs/messaging.c | 16
1 files changed, 12 insertions(+), 4 deletions(-)
diff --git a/fs/ecryptfs/messaging.c b/fs/ecryptfs/messaging.c
index f0d74b8..61506e5 100644
--- a/fs/ecryptfs/messaging.c
+++ b/fs/ecryptfs/messaging.c
@@ -20,6 +20,8 @@
* 02111-1307, USA.
*/
#include linux/sched.h
+#include linux/user_namespace.h
+#include linux/nsproxy.h
#include ecryptfs_kernel.h
static LIST_HEAD(ecryptfs_msg_ctx_free_list);
@@ -208,8 +210,8 @@ ecryptfs_spawn_daemon(struct ecryptfs_daemon **daemon,
uid_t euid,
goto out;
}
(*daemon)-euid = euid;
- (*daemon)-user_ns = user_ns;
- (*daemon)-pid = pid;
+ (*daemon)-user_ns = get_user_ns(user_ns);
+ (*daemon)-pid = get_pid(pid);
(*daemon)-task = current;
mutex_init((*daemon)-mux);
INIT_LIST_HEAD((*daemon)-msg_ctx_out_queue);
@@ -298,6 +300,10 @@ int ecryptfs_exorcise_daemon(struct ecryptfs_daemon
*daemon)
hlist_del(daemon-euid_chain);
if (daemon-task)
wake_up_process(daemon-task);
+ if (daemon-pid)
+ put_pid(daemon-pid);
+ if (daemon-user_ns)
+ put_user_ns(daemon-user_ns);
mutex_unlock(daemon-mux);
memset(daemon, 0, sizeof(*daemon));
kfree(daemon);
@@ -368,6 +374,7 @@ int ecryptfs_process_response(struct ecryptfs_message *msg,
uid_t euid,
struct ecryptfs_msg_ctx *msg_ctx;
size_t msg_size;
struct nsproxy *nsproxy;
+ struct user_namespace *current_user_ns;
int rc;
if (msg-index = ecryptfs_message_buf_len) {
@@ -391,8 +398,9 @@ int ecryptfs_process_response(struct ecryptfs_message *msg,
uid_t euid,
mutex_unlock(ecryptfs_daemon_hash_mux);
goto wake_up;
}
+ current_user_ns = nsproxy-user_ns;
rc = ecryptfs_find_daemon_by_euid(daemon, msg_ctx-task-euid,
- nsproxy-user_ns);
+ current_user_ns);
rcu_read_unlock();
mutex_unlock(ecryptfs_daemon_hash_mux);
if (rc) {
@@ -410,7 +418,7 @@ int ecryptfs_process_response(struct ecryptfs_message *msg,
uid_t euid,
euid, msg_ctx-task-euid);
goto unlock;
}
- if (nsproxy-user_ns != user_ns) {
+ if (current_user_ns != user_ns) {
rc = -EBADMSG;
printk(KERN_WARNING %s
Re: [Ecryptfs-devel] [PATCH] Fix ecryptfsd argument handling
On Tue, Jun 10, 2008 at 11:41:23AM -0500, Tyler Hicks wrote:
Remove colons following short opts that don't require arguments.
If foreground functionality is requested, log syslog messages to
stderr and system logs. Also, add daemon name and pid as syslog
prefix.
Merged.
Signed-off-by: Tyler Hicks [EMAIL PROTECTED]
---
src/daemon/main.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/src/daemon/main.c b/src/daemon/main.c
index cceb487..5e44a53 100644
--- a/src/daemon/main.c
+++ b/src/daemon/main.c
@@ -271,7 +271,7 @@ int main(int argc, char **argv)
{help\0\t\t\tShow usage information, no_argument, NULL, 'h'},
{NULL, 0, NULL, 0}
};
- static char *short_options = p:f:C:R:V:d:h;
+ static char *short_options = p:fC:R:Vd:h;
int long_options_ret;
struct rlimit core = {0, 0};
int foreground = 0;
@@ -327,6 +327,7 @@ int main(int argc, char **argv)
break;
}
}
+ openlog(argv[0], LOG_PID | (foreground ? LOG_PERROR : 0), 0);
if (!messaging_type_specified) {
uint32_t version;
pgp54UpOxaDHi.pgp
Description: PGP signature
-
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php___
eCryptfs-devel mailing list
eCryptfs-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ecryptfs-devel
Re: [Ecryptfs-devel] [PATCH] Build cleanps
On Tue, Jun 10, 2008 at 12:02:19AM +0300, Alon Bar-Lev wrote:
I am going over all projects I help to allow libtool-2 migration and
cleanups.
Please review.
If you like I can split this into smaller parts.
Merged; in release 47. It worked okay for me on Gentoo and Fedora;
please test on your own systems.
Please consider moving the documentation (except manpage) to
separate project, it will save much of the ugly build stuff from
this project, allow make distcheck work correctly, and provide
smaller tarball for users to download. A separate tarballs (eg
ecryptfs-docs) may be provided for this.
For now, I changed the build targets so that the extra docs will not
break the build if the dependencies aren't installed. They will just
not be included. As you suggest, I will probably rip them out of the
source package sometime in the future.
Attached is a patch with the following modifications:
1. Ready to libtool-2
Add -shared to modules, so that in future the .la and .a will not be
generated.
Current versions of libtool ignore this.
In order to activate libtool-2 support:
Modify configure.ac:
-AC_PROG_LIBTOOL
-#LT_INIT
+#AC_PROG_LIBTOOL
+LT_INIT
Modify Makefile.am:
-#ACLOCAL_AMFLAGS = -I m4
+ACLOCAL_AMFLAGS = -I m4
2. make maintainer-clean clean most of unmonitored files (except of docs).
3. autoupdate modifications
Removes spaces.
AM_CONFIG_HEADER-AC_CONFIG_HEADERS
AC_STDC_HEADERS-AC_HEADER_STDC
4. GNU Source
Replace:
CFLAGS=${CFLAGS} -D_GNU_SOURCE
with:
AC_GNU_SOURCE
Add to src/daemon/main.c (missing):
#include sys/wait.h
Remove __WNOTHREAD from waitpid (unneeded).
5. Distribute ecryptfs.7 in tarball so that pod2man is not required on target.
6. Initial work for separate build directory:
mkdir xxx
cd xxx
../configure
make
Some replacements of top_srcdir and top_builddir
Why initial? As I could not make the design doc work correctly.
7. Remove EXTRA_DIST=*.h from src/include/Makefile.am, replace with explicit
filename.
8. Create pam_ecryptfs directly and not libpam_ecryptfs.
9. Introduce DISTCHECK_HACK variable to disable tests and uninstall-local
targets
so make distcheck work.
10. Add some dependency to install-hooks to fix parallel make potential
issues.
Regards,
Alon Bar-Lev.
---
diff --git a/Makefile.am b/Makefile.am
index f0cb95c..a9dbfaa 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -9,6 +9,19 @@
# implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
AUTOMAKE_OPTIONS=foreign dist-bzip2
+#ACLOCAL_AMFLAGS = -I m4
+
+MAINTAINERCLEANFILES = \
+ config.log config.status \
+ $(srcdir)/Makefile.in \
+ $(srcdir)/config.h.in $(srcdir)/config.h.in~ $(srcdir)/configure \
+ $(srcdir)/install-sh $(srcdir)/ltmain.sh $(srcdir)/missing \
+ $(srcdir)/compile $(srcdir)/depcomp $(srcdir)/aclocal.m4 \
+ $(srcdir)/config.guess $(srcdir)/config.sub \
+ $(srcdir)/m4/ltsugar.m4 $(srcdir)/m4/libtool.m4 \
+ $(srcdir)/m4/ltversion.m4 $(srcdir)/m4/lt~obsolete.m4 \
+ $(srcdir)/m4/ltoptions.m4
+
SUBDIRS = doc src
dist_doc_DATA = README
diff --git a/configure.ac b/configure.ac
index d7cb6d9..362e1da 100644
--- a/configure.ac
+++ b/configure.ac
@@ -9,13 +9,14 @@
# implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
-AC_PREREQ([2.59])
+AC_PREREQ(2.59)
AC_INIT([ecryptfs-utils],[46])
AC_CANONICAL_HOST
AC_CANONICAL_TARGET
AM_INIT_AUTOMAKE([${PACKAGE_NAME}], [${PACKAGE_VERSION}])
AC_CONFIG_SRCDIR([src/libecryptfs])
-AM_CONFIG_HEADER([config.h])
+AC_CONFIG_HEADERS([config.h])
+AC_CONFIG_MACRO_DIR([m4])
LIBECRYPTFS_LT_CURRENT=0
LIBECRYPTFS_LT_REVISION=0
@@ -26,56 +27,56 @@ AC_SUBST([LIBECRYPTFS_LT_AGE])
AC_ARG_ENABLE(
[openssl],
- [AC_HELP_STRING([--disable-openssl], [Build OpenSSL key module])],
+ [AS_HELP_STRING([--disable-openssl],[Build OpenSSL key module])],
,
[enable_openssl=detect]
)
AC_ARG_ENABLE(
[pkcs11-helper],
- [AC_HELP_STRING([--enable-pkcs11-helper], [Build pkcs11-helper key
module])],
+ [AS_HELP_STRING([--enable-pkcs11-helper],[Build pkcs11-helper key
module])],
,
enable_pkcs11_helper=no
)
AC_ARG_ENABLE(
[tspi],
- [AC_HELP_STRING([--enable-tspi], [Build TrouSerS key module])],
+ [AS_HELP_STRING([--enable-tspi],[Build TrouSerS key module])],
,
[enable_tspi=no]
)
AC_ARG_ENABLE(
[gpg],
- [AC_HELP_STRING([--enable-gpg], [Build GnuPG key module])],
+ [AS_HELP_STRING([--enable-gpg],[Build GnuPG key module])],
,
[enable_gpg=no]
)
AC_ARG_ENABLE(
[pam],
- [AC_HELP_STRING([--disable-pam], [Build PAM module])],
+ [AS_HELP_STRING([--disable-pam],[Build PAM module])],
,
[enable_pam=yes]
)
AC_ARG_ENABLE(
[gui],
- [AC_HELP_STRING([--enable-gui], [Enable building of GUI components])],
+
Re: [Ecryptfs-devel] [PATCH] ecryptfs-setup-private: don't echo passwords to screen
On Wed, Aug 20, 2008 at 11:45:21PM +0100, Dustin Kirkland wrote: [PATCH] ecryptfs-setup-private: don't echo passwords to screen Merged. This patch fixes some mostly debug code I've used for a while. It's ready for prime time now, and shouldn't really be displaying these on standard out for should surfers to see. diff -upr ecryptfs-utils-53/src/utils/ecryptfs-setup-private ecryptfs-utils-53.new/src/utils/ecryptfs-setup-private --- ecryptfs-utils-53/src/utils/ecryptfs-setup-private2008-08-20 23:06:09.220683144 +0100 +++ ecryptfs-utils-53.new/src/utils/ecryptfs-setup-private2008-08-20 23:13:45.051913720 +0100 @@ -155,6 +155,7 @@ if [ -z $MOUNTPASS ]; then # Pull 128 bits of random data from /dev/urandom, and convert # to a string of 32 hex digits MOUNTPASS=`head -c 16 /dev/urandom | od -x | head -n 1 |sed s/^000// | sed s/\s*//g` + RANDOM_MOUNTPASS=1 break else stty -echo @@ -171,21 +172,24 @@ if [ -z $MOUNTPASS ]; then done fi -echo -echo -echo Using username [$USER] -echo Using mount passphrase [$MOUNTPASS] -echo Using login passphrase [$LOGINPASS] -echo Using mount point [$MOUNTPOINT] -echo Using encrypted dir [$CRYPTDIR] -echo -echo This script will attempt to set up your system to mount -echo $MOUNTPOINT with eCryptfs automatically on login, -echo using your login passphrase. +#echo +#echo Using username [$USER] +#echo Using mount passphrase [$MOUNTPASS] +#echo Using login passphrase [$LOGINPASS] +#echo Using mount point [$MOUNTPOINT] +#echo Using encrypted dir [$CRYPTDIR] +#echo +#echo This script will attempt to set up your system to mount +#echo $MOUNTPOINT with eCryptfs automatically on login, +#echo using your login passphrase. echo echo -echo YOU SHOULD RECORD THIS MOUNT PASSPHRASE AND STORE IN A SAFE LOCATION: -echo $MOUNTPASS +if [ $RANDOM_MOUNTPASS = 1 ]; then + echo YOU SHOULD RECORD THIS MOUNT PASSPHRASE AND STORE IN A SAFE LOCATION: + echo $MOUNTPASS +else + echo YOU SHOULD RECORD YOUR MOUNT PASSPHRASE AND STORE IN A SAFE LOCATION: +fi echo THIS WILL BE REQUIRED IF YOU NEED TO RECOVER YOUR DATA AT A LATER TIME. echo echo - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ eCryptfs-devel mailing list eCryptfs-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ecryptfs-devel pgpQ4LX2bEg0N.pgp Description: PGP signature - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/___ eCryptfs-devel mailing list eCryptfs-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ecryptfs-devel
Re: [Ecryptfs-devel] [PATCH] ecryptfs-setup-private: check that directories are empty before setting up
On Fri, Aug 22, 2008 at 12:46:57PM +0100, Dustin Kirkland wrote: [PATCH] ecryptfs-setup-private: check that directories are empty before setting up Merged. ecryptfs-setup-private should check that Private and .Private are empty before setting up. If data already exists in ~/Private, and pam_ecryptfs regularly performs a mount on top of it, then the that data would be hidden from view, and not encrypted (as the user might expect). If data already exists in ~/.Private, then that's likely encrypted data, which will probably not be readable once we generate a new mounting passphrase, etc. Thus, we need to stop ecryptfs-setup-private and tell the user to clear out those directories before proceeding. *** Note, it would be very nice to provide a utility to encrypt the existing data in place, in an existing Private directory. Would could uses something like rsync -a to copy the data to a tempdir, perform the ecryptfs mount, and then sync the data back into place. However, all sorts of race conditions could occur, with other processes potentially reading/writing data during the encryption migration--a much harder problem to solve than it initially seems. diff -upr ecryptfs-utils-53/src/utils/ecryptfs-setup-private ecryptfs-utils-53.new/src/utils/ecryptfs-setup-private --- ecryptfs-utils-53/src/utils/ecryptfs-setup-private2008-08-22 12:01:30.043671882 +0100 +++ ecryptfs-utils-53.new/src/utils/ecryptfs-setup-private2008-08-22 12:10:15.771880356 +0100 @@ -118,6 +118,18 @@ CRYPTDIR=$HOME/.$PRIVATE_DIR grep -qs $MOUNTPOINT /proc/mounts error [$MOUNTPOINT] is already mounted grep -qs $CRYPTDIR /proc/mounts error [$CRYPTDIR] is already mounted +# Check that the mount point and encrypted directory are empty. +# Perhaps one day we could provide a migration mode (using rsync or something), +# but this would be VERY hard to do safely. +count=`ls -Al $MOUNTPOINT 2/dev/null | grep -v ^total | grep -v ^l.*mount.ecryptfs_private$ | wc -l` +if [ $count != 0 ]; then + error $MOUNTPOINT must be empty before proceeding +fi +count=`ls -Al $CRYPTDIR 2/dev/null | grep -v ^total | wc -l` +if [ $count != 0 ]; then + error $CRYPTDIR must be empty before proceeding +fi + stty_orig=`stty -g` # Prompt for the LOGINPASS, if not on the command line and not in the environment if [ -z $LOGINPASS ]; then - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ eCryptfs-devel mailing list eCryptfs-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ecryptfs-devel pgpOgV9LMlgjs.pgp Description: PGP signature - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/___ eCryptfs-devel mailing list eCryptfs-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ecryptfs-devel
Re: [Ecryptfs-devel] [PATCH] ecryptfs: fix memory corruption when storing crypto info in xattrs
On Wed, Oct 22, 2008 at 12:14:00PM -0500, Eric Sandeen wrote:
When ecryptfs allocates space to write crypto headers into, before
copying it out to file headers or to xattrs, it looks at the value of
crypt_stat-num_header_bytes_at_front to determine how much space it
needs. This is also used as the file offset to the actual encrypted
data, so for xattr-stored crypto info, the value was zero.
So, we kzalloc'd 0 bytes, and then ran off to write to that memory.
(Which returned as ZERO_SIZE_PTR, so we explode quickly).
The right answer is to always allocate a page to write into; the current
code won't ever write more than that (this is enforced by the
(PAGE_CACHE_SIZE - offset) length in the call to
ecryptfs_generate_key_packet_set). To be explicit about this, we now
send in a max parameter, rather than magically using PAGE_CACHE_SIZE
there.
Also, since the pointer we pass down the callchain eventually gets the
virt_to_page() treatment, we should be using a alloc_page variant, not
kzalloc (see also 7fcba054373d5dfc43d26e243a5c9b92069972ee)
Signed-off-by: Eric Sandeen [EMAIL PROTECTED]
The removal of the memset is okay because it is header information,
which is written to the disk in the clear anyway and is not
sensitive.
Acked-by: Michael Halcrow [EMAIL PROTECTED]
---
Index: linux-2.6.27.x86_64/fs/ecryptfs/crypto.c
===
--- linux-2.6.27.x86_64.orig/fs/ecryptfs/crypto.c
+++ linux-2.6.27.x86_64/fs/ecryptfs/crypto.c
@@ -1251,6 +1251,7 @@ struct kmem_cache *ecryptfs_header_cache
/**
* ecryptfs_write_headers_virt
* @page_virt: The virtual address to write the headers to
+ * @max: The size of memory allocated at page_virt
* @size: Set to the number of bytes written by this function
* @crypt_stat: The cryptographic context
* @ecryptfs_dentry: The eCryptfs dentry
@@ -1278,7 +1279,8 @@ struct kmem_cache *ecryptfs_header_cache
*
* Returns zero on success
*/
-static int ecryptfs_write_headers_virt(char *page_virt, size_t *size,
+static int ecryptfs_write_headers_virt(char *page_virt, size_t max,
+size_t *size,
struct ecryptfs_crypt_stat *crypt_stat,
struct dentry *ecryptfs_dentry)
{
@@ -1296,7 +1298,7 @@ static int ecryptfs_write_headers_virt(c
offset += written;
rc = ecryptfs_generate_key_packet_set((page_virt + offset), crypt_stat,
ecryptfs_dentry, written,
- PAGE_CACHE_SIZE - offset);
+ max - offset);
if (rc)
ecryptfs_printk(KERN_WARNING, Error generating key packet
set; rc = [%d]\n, rc);
@@ -1368,14 +1370,14 @@ int ecryptfs_write_metadata(struct dentr
goto out;
}
/* Released in this function */
- virt = kzalloc(crypt_stat-num_header_bytes_at_front, GFP_KERNEL);
+ virt = (char *)get_zeroed_page(GFP_KERNEL);
if (!virt) {
printk(KERN_ERR %s: Out of memory\n, __func__);
rc = -ENOMEM;
goto out;
}
- rc = ecryptfs_write_headers_virt(virt, size, crypt_stat,
- ecryptfs_dentry);
+ rc = ecryptfs_write_headers_virt(virt, PAGE_CACHE_SIZE, size,
+ crypt_stat, ecryptfs_dentry);
if (unlikely(rc)) {
printk(KERN_ERR %s: Error whilst writing headers; rc = [%d]\n,
__func__, rc);
@@ -1393,8 +1395,7 @@ int ecryptfs_write_metadata(struct dentr
goto out_free;
}
out_free:
- memset(virt, 0, crypt_stat-num_header_bytes_at_front);
- kfree(virt);
+ free_page((unsigned long)virt);
out:
return rc;
}
-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100url=/
___
eCryptfs-devel mailing list
eCryptfs-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ecryptfs-devel
[Ecryptfs-devel] [PATCH] ecryptfs-utils: key escrow
This patch makes the minimal changes necessary to enable passphrase
key escrow and key recovery via a SOAP client/server mechanism. This
is currently at the proof-of-concept level of implementation; there is
ample opportunity to add features. You need Python and SWIG installed
to build the libecryptfs SWIG component. Run key-escrow-server, and
then run escrow-passphrase.py [passphrase] to escrow the key and
retrieve-passphrase.py [sig] to fetch the key from the server and put
it in your keyring, all via localhost. There are all kinds of
opportunities to make this useful and secure, such as stunnel for
client-server communications, some kind of authentication mechanism,
and the ability to specify the remote server and storage
location. This patch just gives a convenient base from which to flesh
out a real key escrow capability.
Signed-off-by: Michael Halcrow [EMAIL PROTECTED]
configure.ac | 38 +++
m4/ac_pkg_swig.m4 | 59 +++
m4/ac_python_devel.m4 | 182 +
m4/swig_python.m4 |7 +
src/Makefile.am|2
src/daemon/main.c |6 -
src/escrow/escrow-passphrase.py| 55 +++
src/escrow/key-escrow-server | 86 +
src/escrow/retrieve-passphrase.py | 39 +++
src/include/ecryptfs.h | 16 ++-
src/libecryptfs-swig/Makefile.am | 16 +++
src/libecryptfs-swig/libecryptfs.i | 17 +++
src/libecryptfs/Makefile.am|2
src/libecryptfs/ecryptfs-stat.c|2
src/libecryptfs/key_management.c | 178 +---
src/libecryptfs/main.c |9 +
16 files changed, 668 insertions(+), 46 deletions(-)
---
diff --git a/configure.ac b/configure.ac
index 1faef7a..ecc976f 100644
--- a/configure.ac
+++ b/configure.ac
@@ -18,6 +18,11 @@ AC_CONFIG_SRCDIR([src/libecryptfs])
AC_CONFIG_HEADERS([config.h])
AC_CONFIG_MACRO_DIR([m4])
+AC_DISABLE_STATIC
+AM_PATH_PYTHON(2.5)
+AC_PROG_SWIG(1.3.31)
+SWIG_PYTHON
+
LIBECRYPTFS_LT_CURRENT=0
LIBECRYPTFS_LT_REVISION=0
LIBECRYPTFS_LT_AGE=0
@@ -26,6 +31,13 @@ AC_SUBST([LIBECRYPTFS_LT_REVISION])
AC_SUBST([LIBECRYPTFS_LT_AGE])
AC_ARG_ENABLE(
+ [pywrap],
+ [AS_HELP_STRING([--disable-pywrap],[Build libecryptfs Python
wrappers])],
+ ,
+ [enable_pywrap=detect]
+)
+
+AC_ARG_ENABLE(
[openssl],
[AS_HELP_STRING([--disable-openssl],[Build OpenSSL key module])],
,
@@ -221,6 +233,30 @@ CFLAGS=${CFLAGS} ${OPENSSL_CFLAGS}
AC_CHECK_HEADER([openssl/rsa.h],, [have_openssl=no])
CFLAGS=${OLD_CFLAGS}
+have_python=no
+have_swig=no
+
+if test x${PYTHON_VERSION} != x ; then
+ have_python=yes
+fi
+
+if test x${SWIG} != x ; then
+ have_swig=yes
+fi
+
+if test ${enable_pywrap} = detect ; then
+if test ${have_python} = yes ; then
+if test ${have_swig} = yes ; then
+enable_pywrap=yes
+fi
+fi
+fi
+
+if test ${enable_pywrap} = yes ; then
+test ${have_python} != yes AC_MSG_ERROR([Python not found])
+test ${have_swig} != yes AC_MSG_ERROR([SWIG not found])
+fi
+
test ${enable_openssl} = detect enable_openssl=${have_openssl}
if test ${enable_openssl} = yes ; then
@@ -307,6 +343,7 @@ AM_CONDITIONAL([BUILD_PKCS11_HELPER], [test
${enable_pkcs11_helper} = yes])
AM_CONDITIONAL([BUILD_TSPI], [test ${enable_tspi} = yes])
AM_CONDITIONAL([BUILD_GPG], [test ${enable_gpg} = yes])
AM_CONDITIONAL([BUILD_PAM], [test ${enable_pam} = yes])
+AM_CONDITIONAL([BUILD_PYWRAP], [test ${enable_pywrap} = yes])
AM_CONDITIONAL([BUILD_GUI], [test ${enable_gui} = yes])
AM_CONDITIONAL([BUILD_DOCS], [test ${enable_docs} = yes])
AM_CONDITIONAL([BUILD_DOCS_GEN], [test ${enable_docs_gen} = yes])
@@ -341,6 +378,7 @@ AC_CONFIG_FILES([
doc/manpage/Makefile
src/pam_ecryptfs/Makefile
src/libecryptfs/libecryptfs.pc
+ src/libecryptfs-swig/Makefile
])
AC_OUTPUT
diff --git a/m4/ac_pkg_swig.m4 b/m4/ac_pkg_swig.m4
new file mode 100644
index 000..b5130ad
--- /dev/null
+++ b/m4/ac_pkg_swig.m4
@@ -0,0 +1,59 @@
+AC_DEFUN([AC_PROG_SWIG],[
+AC_PATH_PROG([SWIG],[swig])
+if test -z $SWIG ; then
+AC_MSG_WARN([cannot find 'swig' program. You should look at
http://www.swig.org])
+SWIG='echo Error: SWIG is not installed. You should look at
http://www.swig.org; ; false'
+elif test -n $1 ; then
+AC_MSG_CHECKING([for SWIG version])
+[swig_version=`$SWIG -version 21 | grep 'SWIG Version' | sed
's/.*\([0-9][0-9]*\.[0-9][0-9]*\.[0-9][0-9]*\).*/\1/g'`]
+AC_MSG_RESULT([$swig_version])
+if test -n $swig_version ; then
+# Calculate the required version number components
+[required=$1]
+[required_major=`echo $required | sed 's
Re: [Ecryptfs-devel] [PATCH] ecryptfs-utils: key escrow
On Thu, Oct 30, 2008 at 11:26:35AM -0500, Dustin Kirkland wrote: On Thu, Oct 30, 2008 at 11:18 AM, Dustin Kirkland [EMAIL PROTECTED] wrote: Also, Mike, do you have any documents, discussing the overarching design? In particular, I'm interested in the use case for key escrow The use case I have in mind is when an employee installs the workstation client and sets up his encrypted location, he is prompted with the option of seamlessly transmitting his key to a key escrow server maintained by the organization. If the user elects to use that service, then his data can be recovered by the company's IT department when he later forgets his passphrase. , and how that maps to the concerns raised in: * http://www.cdt.org/crypto/risks98/ This report addresses risks relating to government legislation mandating key escrow. I do not endorse such legislation. pgpQ5n3zltLjn.pgp Description: PGP signature - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/___ eCryptfs-devel mailing list eCryptfs-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ecryptfs-devel
Re: [Ecryptfs-devel] [PATCH] eCryptfs: check readlink result was not an error before using it
On Thu, Dec 11, 2008 at 07:16:26PM +, Duane Griffin wrote: The result from readlink is being used to index into the link name buffer without checking whether it is a valid length. If readlink returns an error this will fault or cause memory corruption. Signed-off-by: Duane Griffin dua...@dghda.com Acked-by: Michael Halcrow mhalc...@us.ibm.com --- fs/ecryptfs/inode.c |3 ++- 1 files changed, 2 insertions(+), 1 deletions(-) diff --git a/fs/ecryptfs/inode.c b/fs/ecryptfs/inode.c index 89209f0..5e78fc1 100644 --- a/fs/ecryptfs/inode.c +++ b/fs/ecryptfs/inode.c @@ -673,10 +673,11 @@ static void *ecryptfs_follow_link(struct dentry *dentry, struct nameidata *nd) ecryptfs_printk(KERN_DEBUG, Calling readlink w/ dentry-d_name.name = [%s]\n, dentry-d_name.name); rc = dentry-d_inode-i_op-readlink(dentry, (char __user *)buf, len); - buf[rc] = '\0'; set_fs(old_fs); if (rc 0) goto out_free; + else + buf[rc] = '\0'; rc = 0; nd_set_link(nd, buf); goto out; -- SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. The future of the web can't happen without you. Join us at MIX09 to help pave the way to the Next Web now. Learn more and register at http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/ ___ eCryptfs-devel mailing list eCryptfs-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ecryptfs-devel
