20 Apr, 2010
5 commits
-
* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/ecryptfs/ecryptfs-2.6:
eCryptfs: Turn lower lookup error messages into debug messages
eCryptfs: Copy lower directory inode times and size on link
ecryptfs: fix use with tmpfs by removing d_drop from ecryptfs_destroy_inode
ecryptfs: fix error code for missing xattrs in lower fs
eCryptfs: Decrypt symlink target for stat size
eCryptfs: Strip metadata in xattr flag in encrypted view
eCryptfs: Clear buffer before reading in metadata xattr
eCryptfs: Rename ecryptfs_crypt_stat.num_header_bytes_at_front
eCryptfs: Fix metadata in xattr feature regression -
Vaugue warnings about ENAMETOOLONG errors when looking up an encrypted
file name have caused many users to become concerned about their data.
Since this is a rather harmless condition, I'm moving this warning to
only be printed when the ecryptfs_verbosity module param is 1.Signed-off-by: Tyler Hicks
-
The timestamps and size of a lower inode involved in a link() call was
being copied to the upper parent inode. Instead, we should be
copying lower parent inode's timestamps and size to the upper parent
inode. I discovered this bug using the POSIX test suite at Tuxera.Signed-off-by: Tyler Hicks
-
If the lower file system driver has extended attributes disabled,
ecryptfs' own access functions return -ENOSYS instead of -EOPNOTSUPP.
This breaks execution of programs in the ecryptfs mount, since the
kernel expects the latter error when checking for security
capabilities in xattrs.Signed-off-by: Christian Pulvermacher
Cc: stable@kernel.org
Signed-off-by: Tyler Hicks -
Create a getattr handler for eCryptfs symlinks that is capable of
reading the lower target and decrypting its path. Prior to this patch,
a stat's st_size field would represent the strlen of the encrypted path,
while readlink() would return the strlen of the decrypted path. This
could lead to confusion in some userspace applications, since the two
values should be equal.https://bugs.launchpad.net/bugs/524919
Reported-by: Loïc Minier
Cc: stable@kernel.org
Signed-off-by: Tyler Hicks
30 Mar, 2010
1 commit
-
…it slab.h inclusion from percpu.h
percpu.h is included by sched.h and module.h and thus ends up being
included when building most .c files. percpu.h includes slab.h which
in turn includes gfp.h making everything defined by the two files
universally available and complicating inclusion dependencies.percpu.h -> slab.h dependency is about to be removed. Prepare for
this change by updating users of gfp and slab facilities include those
headers directly instead of assuming availability. As this conversion
needs to touch large number of source files, the following script is
used as the basis of conversion.http://userweb.kernel.org/~tj/misc/slabh-sweep.py
The script does the followings.
* Scan files for gfp and slab usages and update includes such that
only the necessary includes are there. ie. if only gfp is used,
gfp.h, if slab is used, slab.h.* When the script inserts a new include, it looks at the include
blocks and try to put the new include such that its order conforms
to its surrounding. It's put in the include block which contains
core kernel includes, in the same order that the rest are ordered -
alphabetical, Christmas tree, rev-Xmas-tree or at the end if there
doesn't seem to be any matching order.* If the script can't find a place to put a new include (mostly
because the file doesn't have fitting include block), it prints out
an error message indicating which .h file needs to be added to the
file.The conversion was done in the following steps.
1. The initial automatic conversion of all .c files updated slightly
over 4000 files, deleting around 700 includes and adding ~480 gfp.h
and ~3000 slab.h inclusions. The script emitted errors for ~400
files.2. Each error was manually checked. Some didn't need the inclusion,
some needed manual addition while adding it to implementation .h or
embedding .c file was more appropriate for others. This step added
inclusions to around 150 files.3. The script was run again and the output was compared to the edits
from #2 to make sure no file was left behind.4. Several build tests were done and a couple of problems were fixed.
e.g. lib/decompress_*.c used malloc/free() wrappers around slab
APIs requiring slab.h to be added manually.5. The script was run on all .h files but without automatically
editing them as sprinkling gfp.h and slab.h inclusions around .h
files could easily lead to inclusion dependency hell. Most gfp.h
inclusion directives were ignored as stuff from gfp.h was usually
wildly available and often used in preprocessor macros. Each
slab.h inclusion directive was examined and added manually as
necessary.6. percpu.h was updated not to include slab.h.
7. Build test were done on the following configurations and failures
were fixed. CONFIG_GCOV_KERNEL was turned off for all tests (as my
distributed build env didn't work with gcov compiles) and a few
more options had to be turned off depending on archs to make things
build (like ipr on powerpc/64 which failed due to missing writeq).* x86 and x86_64 UP and SMP allmodconfig and a custom test config.
* powerpc and powerpc64 SMP allmodconfig
* sparc and sparc64 SMP allmodconfig
* ia64 SMP allmodconfig
* s390 SMP allmodconfig
* alpha SMP allmodconfig
* um on x86_64 SMP allmodconfig8. percpu.h modifications were reverted so that it could be applied as
a separate patch and serve as bisection point.Given the fact that I had only a couple of failures from tests on step
6, I'm fairly confident about the coverage of this conversion patch.
If there is a breakage, it's likely to be something in one of the arch
headers which should be easily discoverable easily on most builds of
the specific arch.Signed-off-by: Tejun Heo <tj@kernel.org>
Guess-its-ok-by: Christoph Lameter <cl@linux-foundation.org>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Lee Schermerhorn <Lee.Schermerhorn@hp.com>
24 Mar, 2010
3 commits
-
We initially read in the first PAGE_CACHE_SIZE of a file to if the
eCryptfs header marker can be found. If it isn't found and
ecryptfs_xattr_metadata was given as a mount option, then the
user.ecryptfs xattr is read into the same buffer. Since the data from
the first page of the file wasn't cleared, it is possible that we think
we've found a second tag 3 or tag 1 packet and then error out after the
packet contents aren't as expected. This patch clears the buffer before
filling it with metadata from the user.ecryptfs xattr.Reviewed-by: Eric Sandeen
Signed-off-by: Tyler Hicks -
This patch renames the num_header_bytes_at_front variable to
metadata_size since it now contains the max size of the metadata.Reviewed-by: Eric Sandeen
Signed-off-by: Tyler Hicks -
Fixes regression in 8faece5f906725c10e7a1f6caf84452abadbdc7b
When using the ecryptfs_xattr_metadata mount option, eCryptfs stores the
metadata (normally stored at the front of the file) in the user.ecryptfs
xattr. This causes ecryptfs_crypt_stat.num_header_bytes_at_front to be
0, since there is no header data at the front of the file. This results
in too much memory being requested and ENOMEM being returned from
ecryptfs_write_metadata().This patch fixes the problem by using the num_header_bytes_at_front
variable for specifying the max size of the metadata, despite whether it
is stored in the header or xattr.Reviewed-by: Eric Sandeen
Signed-off-by: Tyler Hicks
20 Jan, 2010
5 commits
-
ecryptfs_interpose checks if one of the flags passed is
ECRYPTFS_INTERPOSE_FLAG_D_ADD, defined as 0x00000001 in ecryptfs_kernel.h.
But the only user of ecryptfs_interpose to pass a non-zero flag to it, has
hard-coded the value as "1". This could spell trouble if any of these values
changes in the future.Signed-off-by: Erez Zadok
Cc: Dustin Kirkland
Cc: Al Viro
Signed-off-by: Tyler Hicks -
Unnecessary because it would unhash perfectly valid dentries, causing them
to have to be re-looked up the next time they're needed, which presumably is
right after.Signed-off-by: Aseem Rastogi
Signed-off-by: Shrikar archak
Signed-off-by: Erez Zadok
Cc: Saumitra Bhanage
Cc: Al Viro
Signed-off-by: Tyler Hicks -
Signed-off-by: Erez Zadok
Cc: Dustin Kirkland
Cc: Andrew Morton
Cc: Al Viro
Signed-off-by: Tyler Hicks -
The i_blocks field of an eCryptfs inode cannot be trusted, but
generic_fillattr() uses it to instantiate the blocks field of a stat()
syscall when a filesystem doesn't implement its own getattr(). Users
have noticed that the output of du is incorrect on newly created files.This patch creates ecryptfs_getattr() which calls into the lower
filesystem's getattr() so that eCryptfs can use its kstat.blocks value
after calling generic_fillattr(). It is important to note that the
block count includes the eCryptfs metadata stored in the beginning of
the lower file plus any padding used to fill an extent before
encryption.https://bugs.launchpad.net/ecryptfs/+bug/390833
Reported-by: Dominic Sacré
Signed-off-by: Tyler Hicks -
When truncating inodes in the lower filesystem, eCryptfs directly
invoked vmtruncate(). As Christoph Hellwig pointed out, vmtruncate() is
a filesystem helper function, but filesystems may need to do more than
just a call to vmtruncate().This patch moves the lower inode truncation out of ecryptfs_truncate()
and renames the function to truncate_upper(). truncate_upper() updates
an iattr for the lower inode to indicate if the lower inode needs to be
truncated upon return. ecryptfs_setattr() then calls notify_change(),
using the updated iattr for the lower inode, to complete the truncation.For eCryptfs functions needing to truncate, ecryptfs_truncate() is
reintroduced as a simple way to truncate the upper inode to a specified
size and then truncate the lower inode accordingly.https://bugs.launchpad.net/bugs/451368
Reported-by: Christoph Hellwig
Acked-by: Dustin Kirkland
Cc: ecryptfs-devel@lists.launchpad.net
Cc: linux-fsdevel@vger.kernel.org
Signed-off-by: Tyler Hicks
14 Jan, 2010
1 commit
-
If ->follow_link handler return the error, it should decrement
nd->path refcnt. But, ecryptfs_follow_link() doesn't decrement.This patch fix it by using usual nd_set_link() style error handling,
instead of playing with nd->path.Signed-off-by: OGAWA Hirofumi
Signed-off-by: Al Viro
17 Dec, 2009
1 commit
-
This get_nlinks parameter was never used by the only mainline user,
ecryptfs; and it has never been used by unionfs or wrapfs either.Acked-by: Dustin Kirkland
Acked-by: Tyler Hicks
Signed-off-by: Erez Zadok
Signed-off-by: Al Viro
23 Sep, 2009
1 commit
-
When calling vfs_unlink() on the lower dentry, d_delete() turns the
dentry into a negative dentry when the d_count is 1. This eventually
caused a NULL pointer deref when a read() or write() was done and the
negative dentry's d_inode was dereferenced in
ecryptfs_read_update_atime() or ecryptfs_getxattr().Placing mutt's tmpdir in an eCryptfs mount is what initially triggered
the oops and I was able to reproduce it with the following sequence:open("/tmp/upper/foo", O_RDWR|O_CREAT|O_EXCL|O_NOFOLLOW, 0600) = 3
link("/tmp/upper/foo", "/tmp/upper/bar") = 0
unlink("/tmp/upper/foo") = 0
open("/tmp/upper/bar", O_RDWR|O_CREAT|O_NOFOLLOW, 0600) = 4
unlink("/tmp/upper/bar") = 0
write(4, "eCryptfs test\n"..., 14
+++ killed by SIGKILL +++https://bugs.launchpad.net/ecryptfs/+bug/387073
Reported-by: Loïc Minier
Cc: Serge Hallyn
Cc: Dave Kleikamp
Cc: ecryptfs-devel@lists.launchpad.net
Cc: stable
Signed-off-by: Tyler Hicks
28 Apr, 2009
2 commits
-
This warning shows up on 64 bit builds:
fs/ecryptfs/inode.c:693: warning: comparison of distinct pointer types
lacks a castSigned-off-by: Tyler Hicks
-
fs/ecryptfs/inode.c:670: warning: format '%d' expects type 'int', but argument 3 has type 'size_t'
Signed-off-by: Randy Dunlap
Signed-off-by: Tyler Hicks
Cc: Dustin Kirkland
Signed-off-by: Andrew Morton
23 Apr, 2009
2 commits
-
When using filename encryption with eCryptfs, the value of the symlink
in the lower filesystem is encrypted and stored as a Tag 70 packet.
This results in a longer symlink target than if the target value wasn't
encrypted.Users were reporting these messages in their syslog:
[ 45.653441] ecryptfs_parse_tag_70_packet: max_packet_size is [56]; real
packet size is [51]
[ 45.653444] ecryptfs_decode_and_decrypt_filename: Could not parse tag
70 packet from filename; copying through filename as-isThis was due to bufsiz, one the arguments in readlink(), being used to
when allocating the buffer passed to the lower inode's readlink().
That symlink target may be very large, but when decoded and decrypted,
could end up being smaller than bufsize.To fix this, the buffer passed to the lower inode's readlink() will
always be PATH_MAX in size when filename encryption is enabled. Any
necessary truncation occurs after the decoding and decrypting.Signed-off-by: Tyler Hicks
-
This patch locks the lower directory inode's i_mutex before calling
lookup_one_len() to find the appropriate dentry in the lower filesystem.
This bug was found thanks to the warning set in commit 2f9092e1.Signed-off-by: Tyler Hicks
22 Apr, 2009
1 commit
-
ecryptfs_passthrough is a mount option that allows eCryptfs to allow
data to be written to non-eCryptfs files in the lower filesystem. The
passthrough option was causing data corruption due to it not always
being treated as a non-eCryptfs file.The first 8 bytes of an eCryptfs file contains the decrypted file size.
This value was being written to the non-eCryptfs files, too. Also,
extra 0x00 characters were being written to make the file size a
multiple of PAGE_CACHE_SIZE.Signed-off-by: Tyler Hicks
23 Mar, 2009
1 commit
-
If ecryptfs_encrypted_view or ecryptfs_xattr_metadata were being
specified as mount options, a NULL pointer dereference of crypt_stat
was possible during lookup.This patch moves the crypt_stat assignment into
ecryptfs_lookup_and_interpose_lower(), ensuring that crypt_stat
will not be NULL before we attempt to dereference it.Thanks to Dan Carpenter and his static analysis tool, smatch, for
finding this bug.Signed-off-by: Tyler Hicks
Acked-by: Dustin Kirkland
Cc: Dan Carpenter
Cc: Serge Hallyn
Signed-off-by: Linus Torvalds
07 Jan, 2009
3 commits
-
Arguments lower_dentry and ecryptfs_dentry in ecryptfs_create_underlying_file()
have been merged into dentry, now fix it.Signed-off-by: Qinghuang Feng
Cc: Randy Dunlap
Cc: Michael Halcrow
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
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 -
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
06 Jan, 2009
1 commit
-
We used to have rather schizophrenic set of checks for NULL ->i_op even
though it had been eliminated years ago. You'd need to go out of your
way to set it to NULL explicitly _and_ a bunch of code would die on
such inodes anyway. After killing two remaining places that still
did that bogosity, all that crap can go away.Signed-off-by: Al Viro
01 Jan, 2009
1 commit
-
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.Cc: Tyler Hicks
Cc: Dustin Kirkland
Cc: ecryptfs-devel@lists.launchpad.net
Signed-off-by: Duane Griffin
Acked-by: Michael Halcrow
Acked-by: Tyler Hicks
Signed-off-by: Al Viro
27 Jul, 2008
3 commits
-
Incidentally, the name that gives hundreds of false positives on grep
is not a good idea...Signed-off-by: Al Viro
-
Remove the unused mode parameter from vfs_symlink and callers.
Thanks to Tetsuo Handa for noticing.
CC: Tetsuo Handa
Signed-off-by: Miklos Szeredi -
* kill nameidata * argument; map the 3 bits in ->flags anybody cares
about to new MAY_... ones and pass with the mask.
* kill redundant gfs2_iop_permission()
* sanitize ecryptfs_permission()
* fix remaining places where ->permission() instances might barf on new
MAY_... found in mask.The obvious next target in that direction is permission(9)
folded fix for nfs_permission() breakage from Miklos Szeredi
Signed-off-by: Al Viro
25 Jul, 2008
3 commits
-
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 -
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 -
Fixe sparse warnings:
fs/ecryptfs/inode.c:368:15: warning: cast to restricted __be64
fs/ecryptfs/mmap.c:385:12: warning: incorrect type in assignment (different base types)
fs/ecryptfs/mmap.c:385:12: expected unsigned long long [unsigned] [assigned] [usertype] file_size
fs/ecryptfs/mmap.c:385:12: got restricted __be64 [usertype]
fs/ecryptfs/mmap.c:428:12: warning: incorrect type in assignment (different base types)
fs/ecryptfs/mmap.c:428:12: expected unsigned long long [unsigned] [assigned] [usertype] file_size
fs/ecryptfs/mmap.c:428:12: got restricted __be64 [usertype]Signed-off-by: Harvey Harrison
Cc: Michael Halcrow
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
13 May, 2008
1 commit
-
dget(dentry->d_parent) --> dget_parent(dentry)
unlock_parent() is racy and unnecessary. Replace single caller with
unlock_dir().There are several other suspect uses of ->d_parent in ecryptfs...
Signed-off-by: Miklos Szeredi
Cc: Michael Halcrow
Cc: Christoph Hellwig
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
29 Apr, 2008
3 commits
-
Some drivers have duplicated unlikely() macros. IS_ERR() already has
unlikely() in itself.This patch cleans up such pointless code.
Signed-off-by: Hirofumi Nakagawa
Acked-by: David S. Miller
Acked-by: Jeff Garzik
Cc: Paul Clements
Cc: Richard Purdie
Cc: Alessandro Zummo
Cc: David Brownell
Cc: James Bottomley
Cc: Michael Halcrow
Cc: Anton Altaparmakov
Cc: Al Viro
Cc: Carsten Otte
Cc: Patrick McHardy
Cc: Paul Mundt
Cc: Jaroslav Kysela
Cc: Takashi Iwai
Acked-by: Mike Frysinger
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
Callers of notify_change() need to hold i_mutex.
Signed-off-by: Miklos Szeredi
Cc: Michael Halcrow
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
__FUNCTION__ is gcc-specific, use __func__
Signed-off-by: Harvey Harrison
Cc: Michael Halcrow
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
15 Feb, 2008
1 commit
-
This is the central patch of a cleanup series. In most cases there is no good
reason why someone would want to use a dentry for itself. This series reflects
that fact and embeds a struct path into nameidata.Together with the other patches of this series
- it enforced the correct order of getting/releasing the reference count on
pairs
- it prepares the VFS for stacking support since it is essential to have a
struct path in every place where the stack can be traversed
- it reduces the overall code size:without patch series:
text data bss dec hex filename
5321639 858418 715768 6895825 6938d1 vmlinuxwith patch series:
text data bss dec hex filename
5320026 858418 715768 6894212 693284 vmlinuxThis patch:
Switch from nd->{dentry,mnt} to nd->path.{dentry,mnt} everywhere.
[akpm@linux-foundation.org: coding-style fixes]
[akpm@linux-foundation.org: fix cifs]
[akpm@linux-foundation.org: fix smack]
Signed-off-by: Jan Blunck
Signed-off-by: Andreas Gruenbacher
Acked-by: Christoph Hellwig
Cc: Al Viro
Cc: Casey Schaufler
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
07 Feb, 2008
1 commit
-
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
