[PATCH 0/6] fs: Add printf format/argument verification

Various logging messages functions use printf style varargs
without declaring them __attribute__((format(printf...))).
Add the attribute so the compiler can warn about mismatches
and then fix any mismatch warnings.

Joe Perches (6):
  fs/adfs: Add printf format/argument verification and fix fallout
  fs/affs: Add printf format/argument verification and fix fallout
  fs/befs: Add printf format/argument verification and fix fallout
  fs/ecryptfs:  Add printf format/argument verification and fix fallout
  fs/jfs: Add printf format/argument verification
  fs/udf: Add printf format/argument verification

 fs/adfs/adfs.h                |    1 +
 fs/adfs/dir.c                 |    2 +-
 fs/affs/affs.h                |    2 +
 fs/affs/file.c                |   14 ++++---
 fs/befs/befs.h                |    3 ++
 fs/befs/btree.c               |    5 ++-
 fs/befs/datastream.c          |   76 ++++++++++++++++++++++++-----------------
 fs/befs/inode.c               |   11 ++++--
 fs/befs/io.c                  |   12 ++++--
 fs/befs/linuxvfs.c            |   19 ++++++----
 fs/ecryptfs/crypto.c          |   20 ++++++----
 fs/ecryptfs/ecryptfs_kernel.h |    1 +
 fs/ecryptfs/file.c            |    6 ++--
 fs/ecryptfs/keystore.c        |    7 ++--
 fs/ecryptfs/main.c            |    7 ++--
 fs/ecryptfs/mmap.c            |   13 ++++---
 fs/jfs/jfs_superblock.h       |    2 +

Attention Encrypted Home Users...

We're rapidly pushing toward an excellent Ubuntu 10.04 LTS release,
and we have made a few improvements in the way your Encrypted Home's
metadata is stored.

If you configured your Encrypted Home with Ubuntu 9.10 (Karmic) or
Ubuntu 10.04 (Lucid), then no action is required, -- you may stop
reading here.

If you're not sure, and you want to check if you need to read this
email, take a look at your /var/lib/ecryptfs directory. If that
directory is empty, or it does not exist, you may stop reading here.
If that directory has contents, then you may want to continue
reading...

Ubuntu 9.04 (Jaunty) Encrypted Home installations stored eCryptfs
metadata in /var/lib/ecryptfs/$USER. This information is absolutely
required to mount your Encrypted Home Directory. Actually, everything
in here can be re-created if you wrote down your randomly generated
mount passphrase!  Please be absolutely certain that you have recorded
your mount passphrase, on a piece of paper, stored somewhere safely,
separate from your computer!  You can retrieve your randomly generated
passphrase by running the ecryptfs-unwrap-passphrase utility.  Oh, and
don't just copy wrapped-passphrase to your $HOME directory and expect
that to be sufficient.  This is effectively locking your keys in your
car (and your car is an armored vehicle).

For Ubuntu 9.10 (Karmic), new installs actually put this metadata in
/home/.ecryptfs/$USER. This is far more convenient for users who put
all of /home on its own partition, or for users who just simply backup
all of /home.

Attention Jaunty Alpha eCryptfs Users...

The 2.6.28 Linux kernel used by each of the Ubuntu Jaunty Alphas (1-6)
included a bug that may have written arbitrary kernel memory into your
eCryptfs file headers.

Note that Hardy and Intrepid are NOT affected!  And the actual
encrypted data content in your eCryptfs files is not affected.

However, if you run 'strings' on your encrypted data, you may see some
cleartext data used as padding in the first 2 pages of the file
headers.  You can check this with something like:
 $ umount.ecryptfs_private && cd ~/.Private && mount.ecryptfs_private
 $ find . -type f | xargs strings  | egrep ".{20}"

For more information about the technical details and the fix for this
bug, please reference:
 * The original bug report (thanks to Florian Streibelt for the report!)
  * https://bugs.launchpad.net/ecryptfs/+bug/345544
 * The upstream git commit
  * http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=8faece5f906725c10e7a1f6caf84452abadbdc7b

The Ubuntu Jaunty Beta kernel includes the fix, which will correctly
zero the 2 pages of kernel memory allocated for these file headers and
prevent such data leakage on any eCryptfs file writes thereafter.

However, any files encrypted with a previous Jaunty Alpha kernel will
need to be re-encrypted with the new kernel.  Also in Ubuntu Jaunty
Beta, I have included a new utility in ecryptfs-utils-73 to help you
clean your files: ecryptfs-rewrite-file.
 * http://manpages.ubuntu.com/manpages/jaunty/en/man1/ecryptfs-rewrite-file.1.html

Re: [PATCH] eCryptfs: check readlink result was not an error before using it

On Thu, Dec 11, 2008 at 07:16:26PM +0000, 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 <duaneg <at> dghda.com>

Acked-by: Michael Halcrow <mhalcrow <at> 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;

release -64?

Hi guys-

I'd like to roll a -64 release today.  I'm curious of the state of the
key escrow bits, if you're ready to drop this in a released version
yet?  Do you have anything else pressing that you'd want to get in
before rolling a release?

--

-- 
:-Dustin

-------------------------------------------------------------------------
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=100&url=/
_______________________________________________
eCryptfs-devel mailing list
eCryptfs-devel <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/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 <mhalcrow <at> us.ibm.com>

 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 

[PATCH] ecryptfs: fix memory corruption when storing crypto info in xattrs

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 <sandeen <at> redhat.com>
---

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

[PATCH] ecryptfs: readability tweak

Signed-off-by: Nicolas Kaiser <nikai <at> nikai.net>
---

 fs/ecryptfs/keystore.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff -ur a/fs/ecryptfs/keystore.c b/fs/ecryptfs/keystore.c
--- a/fs/ecryptfs/keystore.c	2008-07-13 23:51:29.000000000 +0200
+++ b/fs/ecryptfs/keystore.c	2008-10-09 13:45:55.000000000 +0200
@@ -1655,7 +1655,7 @@
 	ecryptfs_printk(KERN_DEBUG, "Encrypting [%d] bytes of the key\n",
 			crypt_stat->key_size);
 	rc = crypto_blkcipher_encrypt(&desc, &dst_sg, &src_sg,
-				      (*key_rec).enc_key_size);
+				      key_rec->enc_key_size);
 	mutex_unlock(tfm_mutex);
 	if (rc) {
 		printk(KERN_ERR "Error encrypting; rc = [%d]\n", 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=100&url=/
_______________________________________________
eCryptfs-devel mailing list
eCryptfs-devel <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ecryptfs-devel

Multiple mounts of ecryptfs filesystem

Hello,

I found an issue with multiple mounts of a single ecryptfs filesystem. It can be demonstrated in the script below.

The encrypted filesystem crypt is mounted to the mount points user1 and user2. Data written to user2 is not
visible in the directory user1, unless it is unmounted and remounted again.

I suspect the problem with the function ecryptfs_d_revalidate, which calls revalidate of the
lower_dentry in return.

So in this example, after writing to user2, the lower filesystem has a valid cached dentry, but the user1
dentry is now not in sync.

I've attached a very simple quick & dirty patch, which basically disables the dentry cache, but resolves
this problem. The performance impact seems to be low.

Cheers 

  Michael

-------------------------
# crypt contains encrypted files
# user1 and user2 contains decrypted files
mount -t ecryptfs crypt user1 ${OPTIONS} 
mount -t ecryptfs crypt user2 ${OPTIONS} 
echo "Hallo Welt" > user1/test.txt
echo "Hello World" > user2/test.txt

#Reads "Hallo Welt"
cat user1/test.txt

[PATCH] ecryptfs-setup-private: check that directories are empty before setting up

[PATCH] ecryptfs-setup-private: check that directories are empty
before setting up

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.

--

-- 
:-Dustin

[PATCH] ecryptfs-setup-private: don't echo passwords to screen

[PATCH] ecryptfs-setup-private: don't echo passwords to screen

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.

--

-- 
:-Dustin

-------------------------------------------------------------------------
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=100&url=/

_______________________________________________
eCryptfs-devel mailing list
eCryptfs-devel <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ecryptfs-devel