linux-stable.git/fs/ecryptfs, branch v3.4.8

eCryptfs: Properly check for O_RDONLY flag before doing privileged open

2012-07-16T16:04:26+00:00

commit 9fe79d7600497ed8a95c3981cbe5b73ab98222f0 upstream.

If the first attempt at opening the lower file read/write fails,
eCryptfs will retry using a privileged kthread. However, the privileged
retry should not happen if the lower file's inode is read-only because a
read/write open will still be unsuccessful.

The check for determining if the open should be retried was intended to
be based on the access mode of the lower file's open flags being
O_RDONLY, but the check was incorrectly performed. This would cause the
open to be retried by the privileged kthread, resulting in a second
failed open of the lower file. This patch corrects the check to
determine if the open request should be handled by the privileged
kthread.

Signed-off-by: Tyler Hicks 
Reported-by: Dan Carpenter 
Acked-by: Dan Carpenter 
Signed-off-by: Greg Kroah-Hartman

eCryptfs: Fix lockdep warning in miscdev operations

2012-07-16T16:04:26+00:00

commit 60d65f1f07a7d81d3eb3b91fc13fca80f2fdbb12 upstream.

Don't grab the daemon mutex while holding the message context mutex.
Addresses this lockdep warning:

 ecryptfsd/2141 is trying to acquire lock:
  (&ecryptfs_msg_ctx_arr[i].mux){+.+.+.}, at: [] ecryptfs_miscdev_read+0x143/0x470 [ecryptfs]

 but task is already holding lock:
  (&(*daemon)->mux){+.+...}, at: [] ecryptfs_miscdev_read+0x21c/0x470 [ecryptfs]

 which lock already depends on the new lock.

 the existing dependency chain (in reverse order) is:

 -> #1 (&(*daemon)->mux){+.+...}:
        [] lock_acquire+0x9d/0x220
        [] __mutex_lock_common+0x5a/0x4b0
        [] mutex_lock_nested+0x44/0x50
        [] ecryptfs_send_miscdev+0x97/0x120 [ecryptfs]
        [] ecryptfs_send_message+0x134/0x1e0 [ecryptfs]
        [] ecryptfs_generate_key_packet_set+0x2fe/0xa80 [ecryptfs]
        [] ecryptfs_write_metadata+0x108/0x250 [ecryptfs]
        [] ecryptfs_create+0x130/0x250 [ecryptfs]
        [] vfs_create+0xb4/0x120
        [] do_last+0x8c5/0xa10
        [] path_openat+0xd9/0x460
        [] do_filp_open+0x42/0xa0
        [] do_sys_open+0xf8/0x1d0
        [] sys_open+0x21/0x30
        [] system_call_fastpath+0x16/0x1b

 -> #0 (&ecryptfs_msg_ctx_arr[i].mux){+.+.+.}:
        [] __lock_acquire+0x1bf8/0x1c50
        [] lock_acquire+0x9d/0x220
        [] __mutex_lock_common+0x5a/0x4b0
        [] mutex_lock_nested+0x44/0x50
        [] ecryptfs_miscdev_read+0x143/0x470 [ecryptfs]
        [] vfs_read+0xb3/0x180
        [] sys_read+0x4d/0x90
        [] system_call_fastpath+0x16/0x1b

Signed-off-by: Tyler Hicks 
Signed-off-by: Greg Kroah-Hartman

eCryptfs: Gracefully refuse miscdev file ops on inherited/passed files

2012-07-16T16:04:26+00:00

commit 8dc6780587c99286c0d3de747a2946a76989414a upstream.

File operations on /dev/ecryptfs would BUG() when the operations were
performed by processes other than the process that originally opened the
file. This could happen with open files inherited after fork() or file
descriptors passed through IPC mechanisms. Rather than calling BUG(), an
error code can be safely returned in most situations.

In ecryptfs_miscdev_release(), eCryptfs still needs to handle the
release even if the last file reference is being held by a process that
didn't originally open the file. ecryptfs_find_daemon_by_euid() will not
be successful, so a pointer to the daemon is stored in the file's
private_data. The private_data pointer is initialized when the miscdev
file is opened and only used when the file is released.

https://launchpad.net/bugs/994247

Signed-off-by: Tyler Hicks 
Reported-by: Sasha Levin 
Tested-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

ecryptfs: make register_filesystem() the last potential failure exit

2012-03-21T01:29:49+00:00

Signed-off-by: Al Viro

switch touch_atime to struct path

2012-03-21T01:29:41+00:00

Signed-off-by: Al Viro

switch open-coded instances of d_make_root() to new helper

2012-03-21T01:29:35+00:00

Signed-off-by: Al Viro

ecryptfs: don't bother with ->drop_inode()

2012-03-21T01:29:33+00:00

generic_drop_inode() is the default

Signed-off-by: Al Viro

ecryptfs: fix printk format warning for size_t

2012-02-29T00:55:30+00:00

Fix printk format warning (from Linus's suggestion):

on i386:
  fs/ecryptfs/miscdev.c:433:38: warning: format '%lu' expects type 'long unsigned int', but argument 4 has type 'unsigned int'

and on x86_64:
  fs/ecryptfs/miscdev.c:433:38: warning: format '%u' expects type 'unsigned int', but argument 4 has type 'long unsigned int'

Signed-off-by: Randy Dunlap 
Cc:	Geert Uytterhoeven 
Cc:	Tyler Hicks 
Cc:	Dustin Kirkland 
Cc:	ecryptfs@vger.kernel.org
Signed-off-by: Linus Torvalds

ecryptfs: remove the second argument of k[un]map_atomic()

2012-02-16T22:06:27+00:00

Signed-off-by: Cong Wang 
Signed-off-by: Tyler Hicks

eCryptfs: Copy up lower inode attrs after setting lower xattr

2012-02-16T22:06:27+00:00

After passing through a ->setxattr() call, eCryptfs needs to copy the
inode attributes from the lower inode to the eCryptfs inode, as they
may have changed in the lower filesystem's ->setxattr() path.

One example is if an extended attribute containing a POSIX Access
Control List is being set. The new ACL may cause the lower filesystem to
modify the mode of the lower inode and the eCryptfs inode would need to
be updated to reflect the new mode.

https://launchpad.net/bugs/926292

Signed-off-by: Tyler Hicks 
Reported-by: Sebastien Bacher 
Cc: John Johansen 
Cc: