linux.git/fs/ecryptfs/file.c, branch v2.6.30

eCryptfs: Fix data types (int/size_t)

2009-01-06T23:59:22+00:00

Correct several format string data type specifiers.  Correct filename size
data types; they should be size_t rather than int when passed as
parameters to some other functions (although note that the filenames will
never be larger than int).

Signed-off-by: Michael Halcrow 
Cc: Dustin Kirkland 
Cc: Eric Sandeen 
Cc: Tyler Hicks 
Cc: David Kleikamp 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

eCryptfs: Filename Encryption: filldir, lookup, and readlink

2009-01-06T23:59:22+00:00

Make the requisite modifications to ecryptfs_filldir(), ecryptfs_lookup(),
and ecryptfs_readlink() to call out to filename encryption functions.
Propagate filename encryption policy flags from mount-wide crypt_stat to
inode crypt_stat.

Signed-off-by: Michael Halcrow 
Cc: Dustin Kirkland 
Cc: Eric Sandeen 
Cc: Tyler Hicks 
Cc: David Kleikamp 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

add a vfs_fsync helper

2009-01-05T16:54:28+00:00

Fsync currently has a fdatawrite/fdatawait pair around the method call,
and a mutex_lock/unlock of the inode mutex.  All callers of fsync have
to duplicate this, but we have a few and most of them don't quite get
it right.  This patch adds a new vfs_fsync that takes care of this.
It's a little more complicated as usual as ->fsync might get a NULL file
pointer and just a dentry from nfsd, but otherwise gets afile and we
want to take the mapping and file operations from it when it is there.

Notes on the fsync callers:

 - ecryptfs wasn't calling filemap_fdatawrite / filemap_fdatawait on the
   	lower file
 - coda wasn't calling filemap_fdatawrite / filemap_fdatawait on the host
	file, and returning 0 when ->fsync was missing
 - shm wasn't calling either filemap_fdatawrite / filemap_fdatawait nor
   taking i_mutex.  Now given that shared memory doesn't have disk
   backing not doing anything in fsync seems fine and I left it out of
   the vfs_fsync conversion for now, but in that case we might just
   not pass it through to the lower file at all but just call the no-op
   simple_sync_file directly.

[and now actually export vfs_fsync]

Signed-off-by: Christoph Hellwig 
Signed-off-by: Al Viro

eCryptfs: remove retry loop in ecryptfs_readdir()

2008-10-16T18:21:38+00:00

The retry block in ecryptfs_readdir() has been in the eCryptfs code base
for a while, apparently for no good reason.  This loop could potentially
run without terminating.  This patch removes the loop, instead erroring
out if vfs_readdir() on the lower file fails.

Signed-off-by: Michael Halcrow 
Reported-by: Al Viro 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

eCryptfs: Make all persistent file opens delayed

2008-07-24T17:47:31+00:00

There is no good reason to immediately open the lower file, and that can
cause problems with files that the user does not intend to immediately
open, such as device nodes.

This patch removes the persistent file open from the interpose step and
pushes that to the locations where eCryptfs really does need the lower
persistent file, such as just before reading or writing the metadata
stored in the lower file header.

Two functions are jumping to out_dput when they should just be jumping to
out on error paths.  This patch also fixes these.

Signed-off-by: Michael Halcrow 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

eCryptfs: do not try to open device files on mknod

2008-07-24T17:47:31+00:00

When creating device nodes, eCryptfs needs to delay actually opening the lower
persistent file until an application tries to open.  Device handles may not be
backed by anything when they first come into existence.

[Valdis.Kletnieks@vt.edu: build fix]
Signed-off-by: Michael Halcrow 
Cc: 
Signed-off-by: Linus Torvalds

eCryptfs: Privileged kthread for lower file opens

2008-07-24T17:47:30+00:00

eCryptfs would really like to have read-write access to all files in the
lower filesystem.  Right now, the persistent lower file may be opened
read-only if the attempt to open it read-write fails.  One way to keep
from having to do that is to have a privileged kthread that can open the
lower persistent file on behalf of the user opening the eCryptfs file;
this patch implements this functionality.

This patch will properly allow a less-privileged user to open the eCryptfs
file, followed by a more-privileged user opening the eCryptfs file, with
the first user only being able to read and the second user being able to
both read and write.  eCryptfs currently does this wrong; it will wind up
calling vfs_write() on a file that was opened read-only.  This is fixed in
this patch.

Signed-off-by: Michael Halcrow 
Cc: Dave Kleikamp 
Cc: Serge Hallyn 
Cc: Eric Sandeen 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

ecryptfs: fasync BKL pushdown

2008-07-02T21:06:28+00:00

Signed-off-by: Jonathan Corbet

eCryptfs: protect crypt_stat->flags in ecryptfs_open()

2008-04-29T15:06:07+00:00

Make sure crypt_stat->flags is protected with a lock in ecryptfs_open().

Signed-off-by: Michael Halcrow 
Cc: Al Viro 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

eCryptfs: Minor fixes to printk messages

2008-02-06T18:41:12+00:00

The printk statements that result when the user does not have the
proper key available could use some refining.

Signed-off-by: Mike Halcrow 
Cc: Mike Halcrow 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds