original development tree for Linux kernel GTP module; now long in mainline.
You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.

891 lines
25 KiB

include cleanup: Update gfp.h and slab.h includes to prepare for breaking implicit 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 allmodconfig 8. 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>
12 years ago
[PATCH] eCryptfs: xattr flags and mount options This patch set introduces the ability to store cryptographic metadata into an lower file extended attribute rather than the lower file header region. This patch set implements two new mount options: ecryptfs_xattr_metadata - When set, newly created files will have their cryptographic metadata stored in the extended attribute region of the file rather than the header. When storing the data in the file header, there is a minimum of 8KB reserved for the header information for each file, making each file at least 12KB in size. This can take up a lot of extra disk space if the user creates a lot of small files. By storing the data in the extended attribute, each file will only occupy at least of 4KB of space. As the eCryptfs metadata set becomes larger with new features such as multi-key associations, most popular filesystems will not be able to store all of the information in the xattr region in some cases due to space constraints. However, the majority of users will only ever associate one key per file, so most users will be okay with storing their data in the xattr region. This option should be used with caution. I want to emphasize that the xattr must be maintained under all circumstances, or the file will be rendered permanently unrecoverable. The last thing I want is for a user to forget to set an xattr flag in a backup utility, only to later discover that their backups are worthless. ecryptfs_encrypted_view - When set, this option causes eCryptfs to present applications a view of encrypted files as if the cryptographic metadata were stored in the file header, whether the metadata is actually stored in the header or in the extended attributes. No matter what eCryptfs winds up doing in the lower filesystem, I want to preserve a baseline format compatibility for the encrypted files. As of right now, the metadata may be in the file header or in an xattr. There is no reason why the metadata could not be put in a separate file in future versions. Without the compatibility mode, backup utilities would have to know to back up the metadata file along with the files. The semantics of eCryptfs have always been that the lower files are self-contained units of encrypted data, and the only additional information required to decrypt any given eCryptfs file is the key. That is what has always been emphasized about eCryptfs lower files, and that is what users expect. Providing the encrypted view option will provide a way to userspace applications wherein they can always get to the same old familiar eCryptfs encrypted files, regardless of what eCryptfs winds up doing with the metadata behind the scenes. This patch: Add extended attribute support to version bit vector, flags to indicate when xattr or encrypted view modes are enabled, and support for the new mount options. Signed-off-by: Michael Halcrow <mhalcrow@us.ibm.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
15 years ago
eCryptfs: Filename Encryption: mount option Enable mount-wide filename encryption by providing the Filename Encryption Key (FNEK) signature as a mount option. Note that the ecryptfs-utils userspace package versions 61 or later support this option. When mounting with ecryptfs-utils version 61 or later, the mount helper will detect the availability of the passphrase-based filename encryption in the kernel (via the eCryptfs sysfs handle) and query the user interactively as to whether or not he wants to enable the feature for the mount. If the user enables filename encryption, the mount helper will then prompt for the FNEK signature that the user wishes to use, suggesting by default the signature for the mount passphrase that the user has already entered for encrypting the file contents. When not using the mount helper, the user can specify the signature for the passphrase key with the ecryptfs_fnek_sig= mount option. This key must be available in the user's keyring. The mount helper usually takes care of this step. If, however, the user is not mounting with the mount helper, then he will need to enter the passphrase key into his keyring with some other utility prior to mounting, such as ecryptfs-manager. Signed-off-by: Michael Halcrow <mhalcrow@us.ibm.com> Cc: Dustin Kirkland <dustin.kirkland@gmail.com> Cc: Eric Sandeen <sandeen@redhat.com> Cc: Tyler Hicks <tchicks@us.ibm.com> Cc: David Kleikamp <shaggy@us.ibm.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
13 years ago
[PATCH] eCryptfs: xattr flags and mount options This patch set introduces the ability to store cryptographic metadata into an lower file extended attribute rather than the lower file header region. This patch set implements two new mount options: ecryptfs_xattr_metadata - When set, newly created files will have their cryptographic metadata stored in the extended attribute region of the file rather than the header. When storing the data in the file header, there is a minimum of 8KB reserved for the header information for each file, making each file at least 12KB in size. This can take up a lot of extra disk space if the user creates a lot of small files. By storing the data in the extended attribute, each file will only occupy at least of 4KB of space. As the eCryptfs metadata set becomes larger with new features such as multi-key associations, most popular filesystems will not be able to store all of the information in the xattr region in some cases due to space constraints. However, the majority of users will only ever associate one key per file, so most users will be okay with storing their data in the xattr region. This option should be used with caution. I want to emphasize that the xattr must be maintained under all circumstances, or the file will be rendered permanently unrecoverable. The last thing I want is for a user to forget to set an xattr flag in a backup utility, only to later discover that their backups are worthless. ecryptfs_encrypted_view - When set, this option causes eCryptfs to present applications a view of encrypted files as if the cryptographic metadata were stored in the file header, whether the metadata is actually stored in the header or in the extended attributes. No matter what eCryptfs winds up doing in the lower filesystem, I want to preserve a baseline format compatibility for the encrypted files. As of right now, the metadata may be in the file header or in an xattr. There is no reason why the metadata could not be put in a separate file in future versions. Without the compatibility mode, backup utilities would have to know to back up the metadata file along with the files. The semantics of eCryptfs have always been that the lower files are self-contained units of encrypted data, and the only additional information required to decrypt any given eCryptfs file is the key. That is what has always been emphasized about eCryptfs lower files, and that is what users expect. Providing the encrypted view option will provide a way to userspace applications wherein they can always get to the same old familiar eCryptfs encrypted files, regardless of what eCryptfs winds up doing with the metadata behind the scenes. This patch: Add extended attribute support to version bit vector, flags to indicate when xattr or encrypted view modes are enabled, and support for the new mount options. Signed-off-by: Michael Halcrow <mhalcrow@us.ibm.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
15 years ago
eCryptfs: Filename Encryption: mount option Enable mount-wide filename encryption by providing the Filename Encryption Key (FNEK) signature as a mount option. Note that the ecryptfs-utils userspace package versions 61 or later support this option. When mounting with ecryptfs-utils version 61 or later, the mount helper will detect the availability of the passphrase-based filename encryption in the kernel (via the eCryptfs sysfs handle) and query the user interactively as to whether or not he wants to enable the feature for the mount. If the user enables filename encryption, the mount helper will then prompt for the FNEK signature that the user wishes to use, suggesting by default the signature for the mount passphrase that the user has already entered for encrypting the file contents. When not using the mount helper, the user can specify the signature for the passphrase key with the ecryptfs_fnek_sig= mount option. This key must be available in the user's keyring. The mount helper usually takes care of this step. If, however, the user is not mounting with the mount helper, then he will need to enter the passphrase key into his keyring with some other utility prior to mounting, such as ecryptfs-manager. Signed-off-by: Michael Halcrow <mhalcrow@us.ibm.com> Cc: Dustin Kirkland <dustin.kirkland@gmail.com> Cc: Eric Sandeen <sandeen@redhat.com> Cc: Tyler Hicks <tchicks@us.ibm.com> Cc: David Kleikamp <shaggy@us.ibm.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
13 years ago
eCryptfs: Filename Encryption: mount option Enable mount-wide filename encryption by providing the Filename Encryption Key (FNEK) signature as a mount option. Note that the ecryptfs-utils userspace package versions 61 or later support this option. When mounting with ecryptfs-utils version 61 or later, the mount helper will detect the availability of the passphrase-based filename encryption in the kernel (via the eCryptfs sysfs handle) and query the user interactively as to whether or not he wants to enable the feature for the mount. If the user enables filename encryption, the mount helper will then prompt for the FNEK signature that the user wishes to use, suggesting by default the signature for the mount passphrase that the user has already entered for encrypting the file contents. When not using the mount helper, the user can specify the signature for the passphrase key with the ecryptfs_fnek_sig= mount option. This key must be available in the user's keyring. The mount helper usually takes care of this step. If, however, the user is not mounting with the mount helper, then he will need to enter the passphrase key into his keyring with some other utility prior to mounting, such as ecryptfs-manager. Signed-off-by: Michael Halcrow <mhalcrow@us.ibm.com> Cc: Dustin Kirkland <dustin.kirkland@gmail.com> Cc: Eric Sandeen <sandeen@redhat.com> Cc: Tyler Hicks <tchicks@us.ibm.com> Cc: David Kleikamp <shaggy@us.ibm.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
13 years ago
eCryptfs: Filename Encryption: mount option Enable mount-wide filename encryption by providing the Filename Encryption Key (FNEK) signature as a mount option. Note that the ecryptfs-utils userspace package versions 61 or later support this option. When mounting with ecryptfs-utils version 61 or later, the mount helper will detect the availability of the passphrase-based filename encryption in the kernel (via the eCryptfs sysfs handle) and query the user interactively as to whether or not he wants to enable the feature for the mount. If the user enables filename encryption, the mount helper will then prompt for the FNEK signature that the user wishes to use, suggesting by default the signature for the mount passphrase that the user has already entered for encrypting the file contents. When not using the mount helper, the user can specify the signature for the passphrase key with the ecryptfs_fnek_sig= mount option. This key must be available in the user's keyring. The mount helper usually takes care of this step. If, however, the user is not mounting with the mount helper, then he will need to enter the passphrase key into his keyring with some other utility prior to mounting, such as ecryptfs-manager. Signed-off-by: Michael Halcrow <mhalcrow@us.ibm.com> Cc: Dustin Kirkland <dustin.kirkland@gmail.com> Cc: Eric Sandeen <sandeen@redhat.com> Cc: Tyler Hicks <tchicks@us.ibm.com> Cc: David Kleikamp <shaggy@us.ibm.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
13 years ago
eCryptfs: Filename Encryption: mount option Enable mount-wide filename encryption by providing the Filename Encryption Key (FNEK) signature as a mount option. Note that the ecryptfs-utils userspace package versions 61 or later support this option. When mounting with ecryptfs-utils version 61 or later, the mount helper will detect the availability of the passphrase-based filename encryption in the kernel (via the eCryptfs sysfs handle) and query the user interactively as to whether or not he wants to enable the feature for the mount. If the user enables filename encryption, the mount helper will then prompt for the FNEK signature that the user wishes to use, suggesting by default the signature for the mount passphrase that the user has already entered for encrypting the file contents. When not using the mount helper, the user can specify the signature for the passphrase key with the ecryptfs_fnek_sig= mount option. This key must be available in the user's keyring. The mount helper usually takes care of this step. If, however, the user is not mounting with the mount helper, then he will need to enter the passphrase key into his keyring with some other utility prior to mounting, such as ecryptfs-manager. Signed-off-by: Michael Halcrow <mhalcrow@us.ibm.com> Cc: Dustin Kirkland <dustin.kirkland@gmail.com> Cc: Eric Sandeen <sandeen@redhat.com> Cc: Tyler Hicks <tchicks@us.ibm.com> Cc: David Kleikamp <shaggy@us.ibm.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
13 years ago
eCryptfs: Filename Encryption: mount option Enable mount-wide filename encryption by providing the Filename Encryption Key (FNEK) signature as a mount option. Note that the ecryptfs-utils userspace package versions 61 or later support this option. When mounting with ecryptfs-utils version 61 or later, the mount helper will detect the availability of the passphrase-based filename encryption in the kernel (via the eCryptfs sysfs handle) and query the user interactively as to whether or not he wants to enable the feature for the mount. If the user enables filename encryption, the mount helper will then prompt for the FNEK signature that the user wishes to use, suggesting by default the signature for the mount passphrase that the user has already entered for encrypting the file contents. When not using the mount helper, the user can specify the signature for the passphrase key with the ecryptfs_fnek_sig= mount option. This key must be available in the user's keyring. The mount helper usually takes care of this step. If, however, the user is not mounting with the mount helper, then he will need to enter the passphrase key into his keyring with some other utility prior to mounting, such as ecryptfs-manager. Signed-off-by: Michael Halcrow <mhalcrow@us.ibm.com> Cc: Dustin Kirkland <dustin.kirkland@gmail.com> Cc: Eric Sandeen <sandeen@redhat.com> Cc: Tyler Hicks <tchicks@us.ibm.com> Cc: David Kleikamp <shaggy@us.ibm.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
13 years ago
eCryptfs: Filename Encryption: mount option Enable mount-wide filename encryption by providing the Filename Encryption Key (FNEK) signature as a mount option. Note that the ecryptfs-utils userspace package versions 61 or later support this option. When mounting with ecryptfs-utils version 61 or later, the mount helper will detect the availability of the passphrase-based filename encryption in the kernel (via the eCryptfs sysfs handle) and query the user interactively as to whether or not he wants to enable the feature for the mount. If the user enables filename encryption, the mount helper will then prompt for the FNEK signature that the user wishes to use, suggesting by default the signature for the mount passphrase that the user has already entered for encrypting the file contents. When not using the mount helper, the user can specify the signature for the passphrase key with the ecryptfs_fnek_sig= mount option. This key must be available in the user's keyring. The mount helper usually takes care of this step. If, however, the user is not mounting with the mount helper, then he will need to enter the passphrase key into his keyring with some other utility prior to mounting, such as ecryptfs-manager. Signed-off-by: Michael Halcrow <mhalcrow@us.ibm.com> Cc: Dustin Kirkland <dustin.kirkland@gmail.com> Cc: Eric Sandeen <sandeen@redhat.com> Cc: Tyler Hicks <tchicks@us.ibm.com> Cc: David Kleikamp <shaggy@us.ibm.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
13 years ago
[PATCH] eCryptfs: xattr flags and mount options This patch set introduces the ability to store cryptographic metadata into an lower file extended attribute rather than the lower file header region. This patch set implements two new mount options: ecryptfs_xattr_metadata - When set, newly created files will have their cryptographic metadata stored in the extended attribute region of the file rather than the header. When storing the data in the file header, there is a minimum of 8KB reserved for the header information for each file, making each file at least 12KB in size. This can take up a lot of extra disk space if the user creates a lot of small files. By storing the data in the extended attribute, each file will only occupy at least of 4KB of space. As the eCryptfs metadata set becomes larger with new features such as multi-key associations, most popular filesystems will not be able to store all of the information in the xattr region in some cases due to space constraints. However, the majority of users will only ever associate one key per file, so most users will be okay with storing their data in the xattr region. This option should be used with caution. I want to emphasize that the xattr must be maintained under all circumstances, or the file will be rendered permanently unrecoverable. The last thing I want is for a user to forget to set an xattr flag in a backup utility, only to later discover that their backups are worthless. ecryptfs_encrypted_view - When set, this option causes eCryptfs to present applications a view of encrypted files as if the cryptographic metadata were stored in the file header, whether the metadata is actually stored in the header or in the extended attributes. No matter what eCryptfs winds up doing in the lower filesystem, I want to preserve a baseline format compatibility for the encrypted files. As of right now, the metadata may be in the file header or in an xattr. There is no reason why the metadata could not be put in a separate file in future versions. Without the compatibility mode, backup utilities would have to know to back up the metadata file along with the files. The semantics of eCryptfs have always been that the lower files are self-contained units of encrypted data, and the only additional information required to decrypt any given eCryptfs file is the key. That is what has always been emphasized about eCryptfs lower files, and that is what users expect. Providing the encrypted view option will provide a way to userspace applications wherein they can always get to the same old familiar eCryptfs encrypted files, regardless of what eCryptfs winds up doing with the metadata behind the scenes. This patch: Add extended attribute support to version bit vector, flags to indicate when xattr or encrypted view modes are enabled, and support for the new mount options. Signed-off-by: Michael Halcrow <mhalcrow@us.ibm.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
15 years ago
eCryptfs: Filename Encryption: mount option Enable mount-wide filename encryption by providing the Filename Encryption Key (FNEK) signature as a mount option. Note that the ecryptfs-utils userspace package versions 61 or later support this option. When mounting with ecryptfs-utils version 61 or later, the mount helper will detect the availability of the passphrase-based filename encryption in the kernel (via the eCryptfs sysfs handle) and query the user interactively as to whether or not he wants to enable the feature for the mount. If the user enables filename encryption, the mount helper will then prompt for the FNEK signature that the user wishes to use, suggesting by default the signature for the mount passphrase that the user has already entered for encrypting the file contents. When not using the mount helper, the user can specify the signature for the passphrase key with the ecryptfs_fnek_sig= mount option. This key must be available in the user's keyring. The mount helper usually takes care of this step. If, however, the user is not mounting with the mount helper, then he will need to enter the passphrase key into his keyring with some other utility prior to mounting, such as ecryptfs-manager. Signed-off-by: Michael Halcrow <mhalcrow@us.ibm.com> Cc: Dustin Kirkland <dustin.kirkland@gmail.com> Cc: Eric Sandeen <sandeen@redhat.com> Cc: Tyler Hicks <tchicks@us.ibm.com> Cc: David Kleikamp <shaggy@us.ibm.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
13 years ago
eCryptfs: Filename Encryption: mount option Enable mount-wide filename encryption by providing the Filename Encryption Key (FNEK) signature as a mount option. Note that the ecryptfs-utils userspace package versions 61 or later support this option. When mounting with ecryptfs-utils version 61 or later, the mount helper will detect the availability of the passphrase-based filename encryption in the kernel (via the eCryptfs sysfs handle) and query the user interactively as to whether or not he wants to enable the feature for the mount. If the user enables filename encryption, the mount helper will then prompt for the FNEK signature that the user wishes to use, suggesting by default the signature for the mount passphrase that the user has already entered for encrypting the file contents. When not using the mount helper, the user can specify the signature for the passphrase key with the ecryptfs_fnek_sig= mount option. This key must be available in the user's keyring. The mount helper usually takes care of this step. If, however, the user is not mounting with the mount helper, then he will need to enter the passphrase key into his keyring with some other utility prior to mounting, such as ecryptfs-manager. Signed-off-by: Michael Halcrow <mhalcrow@us.ibm.com> Cc: Dustin Kirkland <dustin.kirkland@gmail.com> Cc: Eric Sandeen <sandeen@redhat.com> Cc: Tyler Hicks <tchicks@us.ibm.com> Cc: David Kleikamp <shaggy@us.ibm.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
13 years ago
eCryptfs: Filename Encryption: mount option Enable mount-wide filename encryption by providing the Filename Encryption Key (FNEK) signature as a mount option. Note that the ecryptfs-utils userspace package versions 61 or later support this option. When mounting with ecryptfs-utils version 61 or later, the mount helper will detect the availability of the passphrase-based filename encryption in the kernel (via the eCryptfs sysfs handle) and query the user interactively as to whether or not he wants to enable the feature for the mount. If the user enables filename encryption, the mount helper will then prompt for the FNEK signature that the user wishes to use, suggesting by default the signature for the mount passphrase that the user has already entered for encrypting the file contents. When not using the mount helper, the user can specify the signature for the passphrase key with the ecryptfs_fnek_sig= mount option. This key must be available in the user's keyring. The mount helper usually takes care of this step. If, however, the user is not mounting with the mount helper, then he will need to enter the passphrase key into his keyring with some other utility prior to mounting, such as ecryptfs-manager. Signed-off-by: Michael Halcrow <mhalcrow@us.ibm.com> Cc: Dustin Kirkland <dustin.kirkland@gmail.com> Cc: Eric Sandeen <sandeen@redhat.com> Cc: Tyler Hicks <tchicks@us.ibm.com> Cc: David Kleikamp <shaggy@us.ibm.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
13 years ago
eCryptfs: Filename Encryption: mount option Enable mount-wide filename encryption by providing the Filename Encryption Key (FNEK) signature as a mount option. Note that the ecryptfs-utils userspace package versions 61 or later support this option. When mounting with ecryptfs-utils version 61 or later, the mount helper will detect the availability of the passphrase-based filename encryption in the kernel (via the eCryptfs sysfs handle) and query the user interactively as to whether or not he wants to enable the feature for the mount. If the user enables filename encryption, the mount helper will then prompt for the FNEK signature that the user wishes to use, suggesting by default the signature for the mount passphrase that the user has already entered for encrypting the file contents. When not using the mount helper, the user can specify the signature for the passphrase key with the ecryptfs_fnek_sig= mount option. This key must be available in the user's keyring. The mount helper usually takes care of this step. If, however, the user is not mounting with the mount helper, then he will need to enter the passphrase key into his keyring with some other utility prior to mounting, such as ecryptfs-manager. Signed-off-by: Michael Halcrow <mhalcrow@us.ibm.com> Cc: Dustin Kirkland <dustin.kirkland@gmail.com> Cc: Eric Sandeen <sandeen@redhat.com> Cc: Tyler Hicks <tchicks@us.ibm.com> Cc: David Kleikamp <shaggy@us.ibm.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
13 years ago
eCryptfs: Filename Encryption: mount option Enable mount-wide filename encryption by providing the Filename Encryption Key (FNEK) signature as a mount option. Note that the ecryptfs-utils userspace package versions 61 or later support this option. When mounting with ecryptfs-utils version 61 or later, the mount helper will detect the availability of the passphrase-based filename encryption in the kernel (via the eCryptfs sysfs handle) and query the user interactively as to whether or not he wants to enable the feature for the mount. If the user enables filename encryption, the mount helper will then prompt for the FNEK signature that the user wishes to use, suggesting by default the signature for the mount passphrase that the user has already entered for encrypting the file contents. When not using the mount helper, the user can specify the signature for the passphrase key with the ecryptfs_fnek_sig= mount option. This key must be available in the user's keyring. The mount helper usually takes care of this step. If, however, the user is not mounting with the mount helper, then he will need to enter the passphrase key into his keyring with some other utility prior to mounting, such as ecryptfs-manager. Signed-off-by: Michael Halcrow <mhalcrow@us.ibm.com> Cc: Dustin Kirkland <dustin.kirkland@gmail.com> Cc: Eric Sandeen <sandeen@redhat.com> Cc: Tyler Hicks <tchicks@us.ibm.com> Cc: David Kleikamp <shaggy@us.ibm.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
13 years ago
eCryptfs: Filename Encryption: mount option Enable mount-wide filename encryption by providing the Filename Encryption Key (FNEK) signature as a mount option. Note that the ecryptfs-utils userspace package versions 61 or later support this option. When mounting with ecryptfs-utils version 61 or later, the mount helper will detect the availability of the passphrase-based filename encryption in the kernel (via the eCryptfs sysfs handle) and query the user interactively as to whether or not he wants to enable the feature for the mount. If the user enables filename encryption, the mount helper will then prompt for the FNEK signature that the user wishes to use, suggesting by default the signature for the mount passphrase that the user has already entered for encrypting the file contents. When not using the mount helper, the user can specify the signature for the passphrase key with the ecryptfs_fnek_sig= mount option. This key must be available in the user's keyring. The mount helper usually takes care of this step. If, however, the user is not mounting with the mount helper, then he will need to enter the passphrase key into his keyring with some other utility prior to mounting, such as ecryptfs-manager. Signed-off-by: Michael Halcrow <mhalcrow@us.ibm.com> Cc: Dustin Kirkland <dustin.kirkland@gmail.com> Cc: Eric Sandeen <sandeen@redhat.com> Cc: Tyler Hicks <tchicks@us.ibm.com> Cc: David Kleikamp <shaggy@us.ibm.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
13 years ago
eCryptfs: Filename Encryption: mount option Enable mount-wide filename encryption by providing the Filename Encryption Key (FNEK) signature as a mount option. Note that the ecryptfs-utils userspace package versions 61 or later support this option. When mounting with ecryptfs-utils version 61 or later, the mount helper will detect the availability of the passphrase-based filename encryption in the kernel (via the eCryptfs sysfs handle) and query the user interactively as to whether or not he wants to enable the feature for the mount. If the user enables filename encryption, the mount helper will then prompt for the FNEK signature that the user wishes to use, suggesting by default the signature for the mount passphrase that the user has already entered for encrypting the file contents. When not using the mount helper, the user can specify the signature for the passphrase key with the ecryptfs_fnek_sig= mount option. This key must be available in the user's keyring. The mount helper usually takes care of this step. If, however, the user is not mounting with the mount helper, then he will need to enter the passphrase key into his keyring with some other utility prior to mounting, such as ecryptfs-manager. Signed-off-by: Michael Halcrow <mhalcrow@us.ibm.com> Cc: Dustin Kirkland <dustin.kirkland@gmail.com> Cc: Eric Sandeen <sandeen@redhat.com> Cc: Tyler Hicks <tchicks@us.ibm.com> Cc: David Kleikamp <shaggy@us.ibm.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
13 years ago
eCryptfs: Filename Encryption: mount option Enable mount-wide filename encryption by providing the Filename Encryption Key (FNEK) signature as a mount option. Note that the ecryptfs-utils userspace package versions 61 or later support this option. When mounting with ecryptfs-utils version 61 or later, the mount helper will detect the availability of the passphrase-based filename encryption in the kernel (via the eCryptfs sysfs handle) and query the user interactively as to whether or not he wants to enable the feature for the mount. If the user enables filename encryption, the mount helper will then prompt for the FNEK signature that the user wishes to use, suggesting by default the signature for the mount passphrase that the user has already entered for encrypting the file contents. When not using the mount helper, the user can specify the signature for the passphrase key with the ecryptfs_fnek_sig= mount option. This key must be available in the user's keyring. The mount helper usually takes care of this step. If, however, the user is not mounting with the mount helper, then he will need to enter the passphrase key into his keyring with some other utility prior to mounting, such as ecryptfs-manager. Signed-off-by: Michael Halcrow <mhalcrow@us.ibm.com> Cc: Dustin Kirkland <dustin.kirkland@gmail.com> Cc: Eric Sandeen <sandeen@redhat.com> Cc: Tyler Hicks <tchicks@us.ibm.com> Cc: David Kleikamp <shaggy@us.ibm.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
13 years ago
eCryptfs: Filename Encryption: mount option Enable mount-wide filename encryption by providing the Filename Encryption Key (FNEK) signature as a mount option. Note that the ecryptfs-utils userspace package versions 61 or later support this option. When mounting with ecryptfs-utils version 61 or later, the mount helper will detect the availability of the passphrase-based filename encryption in the kernel (via the eCryptfs sysfs handle) and query the user interactively as to whether or not he wants to enable the feature for the mount. If the user enables filename encryption, the mount helper will then prompt for the FNEK signature that the user wishes to use, suggesting by default the signature for the mount passphrase that the user has already entered for encrypting the file contents. When not using the mount helper, the user can specify the signature for the passphrase key with the ecryptfs_fnek_sig= mount option. This key must be available in the user's keyring. The mount helper usually takes care of this step. If, however, the user is not mounting with the mount helper, then he will need to enter the passphrase key into his keyring with some other utility prior to mounting, such as ecryptfs-manager. Signed-off-by: Michael Halcrow <mhalcrow@us.ibm.com> Cc: Dustin Kirkland <dustin.kirkland@gmail.com> Cc: Eric Sandeen <sandeen@redhat.com> Cc: Tyler Hicks <tchicks@us.ibm.com> Cc: David Kleikamp <shaggy@us.ibm.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
13 years ago
fs: Limit sys_mount to only request filesystem modules. Modify the request_module to prefix the file system type with "fs-" and add aliases to all of the filesystems that can be built as modules to match. A common practice is to build all of the kernel code and leave code that is not commonly needed as modules, with the result that many users are exposed to any bug anywhere in the kernel. Looking for filesystems with a fs- prefix limits the pool of possible modules that can be loaded by mount to just filesystems trivially making things safer with no real cost. Using aliases means user space can control the policy of which filesystem modules are auto-loaded by editing /etc/modprobe.d/*.conf with blacklist and alias directives. Allowing simple, safe, well understood work-arounds to known problematic software. This also addresses a rare but unfortunate problem where the filesystem name is not the same as it's module name and module auto-loading would not work. While writing this patch I saw a handful of such cases. The most significant being autofs that lives in the module autofs4. This is relevant to user namespaces because we can reach the request module in get_fs_type() without having any special permissions, and people get uncomfortable when a user specified string (in this case the filesystem type) goes all of the way to request_module. After having looked at this issue I don't think there is any particular reason to perform any filtering or permission checks beyond making it clear in the module request that we want a filesystem module. The common pattern in the kernel is to call request_module() without regards to the users permissions. In general all a filesystem module does once loaded is call register_filesystem() and go to sleep. Which means there is not much attack surface exposed by loading a filesytem module unless the filesystem is mounted. In a user namespace filesystems are not mounted unless .fs_flags = FS_USERNS_MOUNT, which most filesystems do not set today. Acked-by: Serge Hallyn <serge.hallyn@canonical.com> Acked-by: Kees Cook <keescook@chromium.org> Reported-by: Kees Cook <keescook@google.com> Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
9 years ago
  1. /**
  2. * eCryptfs: Linux filesystem encryption layer
  3. *
  4. * Copyright (C) 1997-2003 Erez Zadok
  5. * Copyright (C) 2001-2003 Stony Brook University
  6. * Copyright (C) 2004-2007 International Business Machines Corp.
  7. * Author(s): Michael A. Halcrow <mahalcro@us.ibm.com>
  8. * Michael C. Thompson <mcthomps@us.ibm.com>
  9. * Tyler Hicks <tyhicks@ou.edu>
  10. *
  11. * This program is free software; you can redistribute it and/or
  12. * modify it under the terms of the GNU General Public License as
  13. * published by the Free Software Foundation; either version 2 of the
  14. * License, or (at your option) any later version.
  15. *
  16. * This program is distributed in the hope that it will be useful, but
  17. * WITHOUT ANY WARRANTY; without even the implied warranty of
  18. * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
  19. * General Public License for more details.
  20. *
  21. * You should have received a copy of the GNU General Public License
  22. * along with this program; if not, write to the Free Software
  23. * Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA
  24. * 02111-1307, USA.
  25. */
  26. #include <linux/dcache.h>
  27. #include <linux/file.h>
  28. #include <linux/module.h>
  29. #include <linux/namei.h>
  30. #include <linux/skbuff.h>
  31. #include <linux/crypto.h>
  32. #include <linux/mount.h>
  33. #include <linux/pagemap.h>
  34. #include <linux/key.h>
  35. #include <linux/parser.h>
  36. #include <linux/fs_stack.h>
  37. #include <linux/slab.h>
  38. #include <linux/magic.h>
  39. #include "ecryptfs_kernel.h"
  40. /**
  41. * Module parameter that defines the ecryptfs_verbosity level.
  42. */
  43. int ecryptfs_verbosity = 0;
  44. module_param(ecryptfs_verbosity, int, 0);
  45. MODULE_PARM_DESC(ecryptfs_verbosity,
  46. "Initial verbosity level (0 or 1; defaults to "
  47. "0, which is Quiet)");
  48. /**
  49. * Module parameter that defines the number of message buffer elements
  50. */
  51. unsigned int ecryptfs_message_buf_len = ECRYPTFS_DEFAULT_MSG_CTX_ELEMS;
  52. module_param(ecryptfs_message_buf_len, uint, 0);
  53. MODULE_PARM_DESC(ecryptfs_message_buf_len,
  54. "Number of message buffer elements");
  55. /**
  56. * Module parameter that defines the maximum guaranteed amount of time to wait
  57. * for a response from ecryptfsd. The actual sleep time will be, more than
  58. * likely, a small amount greater than this specified value, but only less if
  59. * the message successfully arrives.
  60. */
  61. signed long ecryptfs_message_wait_timeout = ECRYPTFS_MAX_MSG_CTX_TTL / HZ;
  62. module_param(ecryptfs_message_wait_timeout, long, 0);
  63. MODULE_PARM_DESC(ecryptfs_message_wait_timeout,
  64. "Maximum number of seconds that an operation will "
  65. "sleep while waiting for a message response from "
  66. "userspace");
  67. /**
  68. * Module parameter that is an estimate of the maximum number of users
  69. * that will be concurrently using eCryptfs. Set this to the right
  70. * value to balance performance and memory use.
  71. */
  72. unsigned int ecryptfs_number_of_users = ECRYPTFS_DEFAULT_NUM_USERS;
  73. module_param(ecryptfs_number_of_users, uint, 0);
  74. MODULE_PARM_DESC(ecryptfs_number_of_users, "An estimate of the number of "
  75. "concurrent users of eCryptfs");
  76. void __ecryptfs_printk(const char *fmt, ...)
  77. {
  78. va_list args;
  79. va_start(args, fmt);
  80. if (fmt[1] == '7') { /* KERN_DEBUG */
  81. if (ecryptfs_verbosity >= 1)
  82. vprintk(fmt, args);
  83. } else
  84. vprintk(fmt, args);
  85. va_end(args);
  86. }
  87. /**
  88. * ecryptfs_init_lower_file
  89. * @ecryptfs_dentry: Fully initialized eCryptfs dentry object, with
  90. * the lower dentry and the lower mount set
  91. *
  92. * eCryptfs only ever keeps a single open file for every lower
  93. * inode. All I/O operations to the lower inode occur through that
  94. * file. When the first eCryptfs dentry that interposes with the first
  95. * lower dentry for that inode is created, this function creates the
  96. * lower file struct and associates it with the eCryptfs
  97. * inode. When all eCryptfs files associated with the inode are released, the
  98. * file is closed.
  99. *
  100. * The lower file will be opened with read/write permissions, if
  101. * possible. Otherwise, it is opened read-only.
  102. *
  103. * This function does nothing if a lower file is already
  104. * associated with the eCryptfs inode.
  105. *
  106. * Returns zero on success; non-zero otherwise
  107. */
  108. static int ecryptfs_init_lower_file(struct dentry *dentry,
  109. struct file **lower_file)
  110. {
  111. const struct cred *cred = current_cred();
  112. struct dentry *lower_dentry = ecryptfs_dentry_to_lower(dentry);
  113. struct vfsmount *lower_mnt = ecryptfs_dentry_to_lower_mnt(dentry);
  114. int rc;
  115. rc = ecryptfs_privileged_open(lower_file, lower_dentry, lower_mnt,
  116. cred);
  117. if (rc) {
  118. printk(KERN_ERR "Error opening lower file "
  119. "for lower_dentry [0x%p] and lower_mnt [0x%p]; "
  120. "rc = [%d]\n", lower_dentry, lower_mnt, rc);
  121. (*lower_file) = NULL;
  122. }
  123. return rc;
  124. }
  125. int ecryptfs_get_lower_file(struct dentry *dentry, struct inode *inode)
  126. {
  127. struct ecryptfs_inode_info *inode_info;
  128. int count, rc = 0;
  129. inode_info = ecryptfs_inode_to_private(inode);
  130. mutex_lock(&inode_info->lower_file_mutex);
  131. count = atomic_inc_return(&inode_info->lower_file_count);
  132. if (WARN_ON_ONCE(count < 1))
  133. rc = -EINVAL;
  134. else if (count == 1) {
  135. rc = ecryptfs_init_lower_file(dentry,
  136. &inode_info->lower_file);
  137. if (rc)
  138. atomic_set(&inode_info->lower_file_count, 0);
  139. }
  140. mutex_unlock(&inode_info->lower_file_mutex);
  141. return rc;
  142. }
  143. void ecryptfs_put_lower_file(struct inode *inode)
  144. {
  145. struct ecryptfs_inode_info *inode_info;
  146. inode_info = ecryptfs_inode_to_private(inode);
  147. if (atomic_dec_and_mutex_lock(&inode_info->lower_file_count,
  148. &inode_info->lower_file_mutex)) {
  149. filemap_write_and_wait(inode->i_mapping);
  150. fput(inode_info->lower_file);
  151. inode_info->lower_file = NULL;
  152. mutex_unlock(&inode_info->lower_file_mutex);
  153. }
  154. }
  155. enum { ecryptfs_opt_sig, ecryptfs_opt_ecryptfs_sig,
  156. ecryptfs_opt_cipher, ecryptfs_opt_ecryptfs_cipher,
  157. ecryptfs_opt_ecryptfs_key_bytes,
  158. ecryptfs_opt_passthrough, ecryptfs_opt_xattr_metadata,
  159. ecryptfs_opt_encrypted_view, ecryptfs_opt_fnek_sig,
  160. ecryptfs_opt_fn_cipher, ecryptfs_opt_fn_cipher_key_bytes,
  161. ecryptfs_opt_unlink_sigs, ecryptfs_opt_mount_auth_tok_only,
  162. ecryptfs_opt_check_dev_ruid,
  163. ecryptfs_opt_err };
  164. static const match_table_t tokens = {
  165. {ecryptfs_opt_sig, "sig=%s"},
  166. {ecryptfs_opt_ecryptfs_sig, "ecryptfs_sig=%s"},
  167. {ecryptfs_opt_cipher, "cipher=%s"},
  168. {ecryptfs_opt_ecryptfs_cipher, "ecryptfs_cipher=%s"},
  169. {ecryptfs_opt_ecryptfs_key_bytes, "ecryptfs_key_bytes=%u"},
  170. {ecryptfs_opt_passthrough, "ecryptfs_passthrough"},
  171. {ecryptfs_opt_xattr_metadata, "ecryptfs_xattr_metadata"},
  172. {ecryptfs_opt_encrypted_view, "ecryptfs_encrypted_view"},
  173. {ecryptfs_opt_fnek_sig, "ecryptfs_fnek_sig=%s"},
  174. {ecryptfs_opt_fn_cipher, "ecryptfs_fn_cipher=%s"},
  175. {ecryptfs_opt_fn_cipher_key_bytes, "ecryptfs_fn_key_bytes=%u"},
  176. {ecryptfs_opt_unlink_sigs, "ecryptfs_unlink_sigs"},
  177. {ecryptfs_opt_mount_auth_tok_only, "ecryptfs_mount_auth_tok_only"},
  178. {ecryptfs_opt_check_dev_ruid, "ecryptfs_check_dev_ruid"},
  179. {ecryptfs_opt_err, NULL}
  180. };
  181. static int ecryptfs_init_global_auth_toks(
  182. struct ecryptfs_mount_crypt_stat *mount_crypt_stat)
  183. {
  184. struct ecryptfs_global_auth_tok *global_auth_tok;
  185. struct ecryptfs_auth_tok *auth_tok;
  186. int rc = 0;
  187. list_for_each_entry(global_auth_tok,
  188. &mount_crypt_stat->global_auth_tok_list,
  189. mount_crypt_stat_list) {
  190. rc = ecryptfs_keyring_auth_tok_for_sig(
  191. &global_auth_tok->global_auth_tok_key, &auth_tok,
  192. global_auth_tok->sig);
  193. if (rc) {
  194. printk(KERN_ERR "Could not find valid key in user "
  195. "session keyring for sig specified in mount "
  196. "option: [%s]\n", global_auth_tok->sig);
  197. global_auth_tok->flags |= ECRYPTFS_AUTH_TOK_INVALID;
  198. goto out;
  199. } else {
  200. global_auth_tok->flags &= ~ECRYPTFS_AUTH_TOK_INVALID;
  201. up_write(&(global_auth_tok->global_auth_tok_key)->sem);
  202. }
  203. }
  204. out:
  205. return rc;
  206. }
  207. static void ecryptfs_init_mount_crypt_stat(
  208. struct ecryptfs_mount_crypt_stat *mount_crypt_stat)
  209. {
  210. memset((void *)mount_crypt_stat, 0,
  211. sizeof(struct ecryptfs_mount_crypt_stat));
  212. INIT_LIST_HEAD(&mount_crypt_stat->global_auth_tok_list);
  213. mutex_init(&mount_crypt_stat->global_auth_tok_list_mutex);
  214. mount_crypt_stat->flags |= ECRYPTFS_MOUNT_CRYPT_STAT_INITIALIZED;
  215. }
  216. /**
  217. * ecryptfs_parse_options
  218. * @sb: The ecryptfs super block
  219. * @options: The options passed to the kernel
  220. * @check_ruid: set to 1 if device uid should be checked against the ruid
  221. *
  222. * Parse mount options:
  223. * debug=N - ecryptfs_verbosity level for debug output
  224. * sig=XXX - description(signature) of the key to use
  225. *
  226. * Returns the dentry object of the lower-level (lower/interposed)
  227. * directory; We want to mount our stackable file system on top of
  228. * that lower directory.
  229. *
  230. * The signature of the key to use must be the description of a key
  231. * already in the keyring. Mounting will fail if the key can not be
  232. * found.
  233. *
  234. * Returns zero on success; non-zero on error
  235. */
  236. static int ecryptfs_parse_options(struct ecryptfs_sb_info *sbi, char *options,
  237. uid_t *check_ruid)
  238. {
  239. char *p;
  240. int rc = 0;
  241. int sig_set = 0;
  242. int cipher_name_set = 0;
  243. int fn_cipher_name_set = 0;
  244. int cipher_key_bytes;
  245. int cipher_key_bytes_set = 0;
  246. int fn_cipher_key_bytes;
  247. int fn_cipher_key_bytes_set = 0;
  248. struct ecryptfs_mount_crypt_stat *mount_crypt_stat =
  249. &sbi->mount_crypt_stat;
  250. substring_t args[MAX_OPT_ARGS];
  251. int token;
  252. char *sig_src;
  253. char *cipher_name_dst;
  254. char *cipher_name_src;
  255. char *fn_cipher_name_dst;
  256. char *fn_cipher_name_src;
  257. char *fnek_dst;
  258. char *fnek_src;
  259. char *cipher_key_bytes_src;
  260. char *fn_cipher_key_bytes_src;
  261. u8 cipher_code;
  262. *check_ruid = 0;
  263. if (!options) {
  264. rc = -EINVAL;
  265. goto out;
  266. }
  267. ecryptfs_init_mount_crypt_stat(mount_crypt_stat);
  268. while ((p = strsep(&options, ",")) != NULL) {
  269. if (!*p)
  270. continue;
  271. token = match_token(p, tokens, args);
  272. switch (token) {
  273. case ecryptfs_opt_sig:
  274. case ecryptfs_opt_ecryptfs_sig:
  275. sig_src = args[0].from;
  276. rc = ecryptfs_add_global_auth_tok(mount_crypt_stat,
  277. sig_src, 0);
  278. if (rc) {
  279. printk(KERN_ERR "Error attempting to register "
  280. "global sig; rc = [%d]\n", rc);
  281. goto out;
  282. }
  283. sig_set = 1;
  284. break;
  285. case ecryptfs_opt_cipher:
  286. case ecryptfs_opt_ecryptfs_cipher:
  287. cipher_name_src = args[0].from;
  288. cipher_name_dst =
  289. mount_crypt_stat->
  290. global_default_cipher_name;
  291. strncpy(cipher_name_dst, cipher_name_src,
  292. ECRYPTFS_MAX_CIPHER_NAME_SIZE);
  293. cipher_name_dst[ECRYPTFS_MAX_CIPHER_NAME_SIZE] = '\0';
  294. cipher_name_set = 1;
  295. break;
  296. case ecryptfs_opt_ecryptfs_key_bytes:
  297. cipher_key_bytes_src = args[0].from;
  298. cipher_key_bytes =
  299. (int)simple_strtol(cipher_key_bytes_src,
  300. &cipher_key_bytes_src, 0);
  301. mount_crypt_stat->global_default_cipher_key_size =
  302. cipher_key_bytes;
  303. cipher_key_bytes_set = 1;
  304. break;
  305. case ecryptfs_opt_passthrough:
  306. mount_crypt_stat->flags |=
  307. ECRYPTFS_PLAINTEXT_PASSTHROUGH_ENABLED;
  308. break;
  309. case ecryptfs_opt_xattr_metadata:
  310. mount_crypt_stat->flags |=
  311. ECRYPTFS_XATTR_METADATA_ENABLED;
  312. break;
  313. case ecryptfs_opt_encrypted_view:
  314. mount_crypt_stat->flags |=
  315. ECRYPTFS_XATTR_METADATA_ENABLED;
  316. mount_crypt_stat->flags |=
  317. ECRYPTFS_ENCRYPTED_VIEW_ENABLED;
  318. break;
  319. case ecryptfs_opt_fnek_sig:
  320. fnek_src = args[0].from;
  321. fnek_dst =
  322. mount_crypt_stat->global_default_fnek_sig;
  323. strncpy(fnek_dst, fnek_src, ECRYPTFS_SIG_SIZE_HEX);
  324. mount_crypt_stat->global_default_fnek_sig[
  325. ECRYPTFS_SIG_SIZE_HEX] = '\0';
  326. rc = ecryptfs_add_global_auth_tok(
  327. mount_crypt_stat,
  328. mount_crypt_stat->global_default_fnek_sig,
  329. ECRYPTFS_AUTH_TOK_FNEK);
  330. if (rc) {
  331. printk(KERN_ERR "Error attempting to register "
  332. "global fnek sig [%s]; rc = [%d]\n",
  333. mount_crypt_stat->global_default_fnek_sig,
  334. rc);
  335. goto out;
  336. }
  337. mount_crypt_stat->flags |=
  338. (ECRYPTFS_GLOBAL_ENCRYPT_FILENAMES
  339. | ECRYPTFS_GLOBAL_ENCFN_USE_MOUNT_FNEK);
  340. break;
  341. case ecryptfs_opt_fn_cipher:
  342. fn_cipher_name_src = args[0].from;
  343. fn_cipher_name_dst =
  344. mount_crypt_stat->global_default_fn_cipher_name;
  345. strncpy(fn_cipher_name_dst, fn_cipher_name_src,
  346. ECRYPTFS_MAX_CIPHER_NAME_SIZE);
  347. mount_crypt_stat->global_default_fn_cipher_name[
  348. ECRYPTFS_MAX_CIPHER_NAME_SIZE] = '\0';
  349. fn_cipher_name_set = 1;
  350. break;
  351. case ecryptfs_opt_fn_cipher_key_bytes:
  352. fn_cipher_key_bytes_src = args[0].from;
  353. fn_cipher_key_bytes =
  354. (int)simple_strtol(fn_cipher_key_bytes_src,
  355. &fn_cipher_key_bytes_src, 0);
  356. mount_crypt_stat->global_default_fn_cipher_key_bytes =
  357. fn_cipher_key_bytes;
  358. fn_cipher_key_bytes_set = 1;
  359. break;
  360. case ecryptfs_opt_unlink_sigs:
  361. mount_crypt_stat->flags |= ECRYPTFS_UNLINK_SIGS;
  362. break;
  363. case ecryptfs_opt_mount_auth_tok_only:
  364. mount_crypt_stat->flags |=
  365. ECRYPTFS_GLOBAL_MOUNT_AUTH_TOK_ONLY;
  366. break;
  367. case ecryptfs_opt_check_dev_ruid:
  368. *check_ruid = 1;
  369. break;
  370. case ecryptfs_opt_err:
  371. default:
  372. printk(KERN_WARNING
  373. "%s: eCryptfs: unrecognized option [%s]\n",
  374. __func__, p);
  375. }
  376. }
  377. if (!sig_set) {
  378. rc = -EINVAL;
  379. ecryptfs_printk(KERN_ERR, "You must supply at least one valid "
  380. "auth tok signature as a mount "
  381. "parameter; see the eCryptfs README\n");
  382. goto out;
  383. }
  384. if (!cipher_name_set) {
  385. int cipher_name_len = strlen(ECRYPTFS_DEFAULT_CIPHER);
  386. BUG_ON(cipher_name_len >= ECRYPTFS_MAX_CIPHER_NAME_SIZE);
  387. strcpy(mount_crypt_stat->global_default_cipher_name,
  388. ECRYPTFS_DEFAULT_CIPHER);
  389. }
  390. if ((mount_crypt_stat->flags & ECRYPTFS_GLOBAL_ENCRYPT_FILENAMES)
  391. && !fn_cipher_name_set)
  392. strcpy(mount_crypt_stat->global_default_fn_cipher_name,
  393. mount_crypt_stat->global_default_cipher_name);
  394. if (!cipher_key_bytes_set)
  395. mount_crypt_stat->global_default_cipher_key_size = 0;
  396. if ((mount_crypt_stat->flags & ECRYPTFS_GLOBAL_ENCRYPT_FILENAMES)
  397. && !fn_cipher_key_bytes_set)
  398. mount_crypt_stat->global_default_fn_cipher_key_bytes =
  399. mount_crypt_stat->global_default_cipher_key_size;
  400. cipher_code = ecryptfs_code_for_cipher_string(
  401. mount_crypt_stat->global_default_cipher_name,
  402. mount_crypt_stat->global_default_cipher_key_size);
  403. if (!cipher_code) {
  404. ecryptfs_printk(KERN_ERR,
  405. "eCryptfs doesn't support cipher: %s",
  406. mount_crypt_stat->global_default_cipher_name);
  407. rc = -EINVAL;
  408. goto out;
  409. }
  410. mutex_lock(&key_tfm_list_mutex);
  411. if (!ecryptfs_tfm_exists(mount_crypt_stat->global_default_cipher_name,
  412. NULL)) {
  413. rc = ecryptfs_add_new_key_tfm(
  414. NULL, mount_crypt_stat->global_default_cipher_name,
  415. mount_crypt_stat->global_default_cipher_key_size);
  416. if (rc) {
  417. printk(KERN_ERR "Error attempting to initialize "
  418. "cipher with name = [%s] and key size = [%td]; "
  419. "rc = [%d]\n",
  420. mount_crypt_stat->global_default_cipher_name,
  421. mount_crypt_stat->global_default_cipher_key_size,
  422. rc);
  423. rc = -EINVAL;
  424. mutex_unlock(&key_tfm_list_mutex);
  425. goto out;
  426. }
  427. }
  428. if ((mount_crypt_stat->flags & ECRYPTFS_GLOBAL_ENCRYPT_FILENAMES)
  429. && !ecryptfs_tfm_exists(
  430. mount_crypt_stat->global_default_fn_cipher_name, NULL)) {
  431. rc = ecryptfs_add_new_key_tfm(
  432. NULL, mount_crypt_stat->global_default_fn_cipher_name,
  433. mount_crypt_stat->global_default_fn_cipher_key_bytes);
  434. if (rc) {
  435. printk(KERN_ERR "Error attempting to initialize "
  436. "cipher with name = [%s] and key size = [%td]; "
  437. "rc = [%d]\n",
  438. mount_crypt_stat->global_default_fn_cipher_name,
  439. mount_crypt_stat->global_default_fn_cipher_key_bytes,
  440. rc);
  441. rc = -EINVAL;
  442. mutex_unlock(&key_tfm_list_mutex);
  443. goto out;
  444. }
  445. }
  446. mutex_unlock(&key_tfm_list_mutex);
  447. rc = ecryptfs_init_global_auth_toks(mount_crypt_stat);
  448. if (rc)
  449. printk(KERN_WARNING "One or more global auth toks could not "
  450. "properly register; rc = [%d]\n", rc);
  451. out:
  452. return rc;
  453. }
  454. struct kmem_cache *ecryptfs_sb_info_cache;
  455. static struct file_system_type ecryptfs_fs_type;
  456. /**
  457. * ecryptfs_get_sb
  458. * @fs_type
  459. * @flags
  460. * @dev_name: The path to mount over
  461. * @raw_data: The options passed into the kernel
  462. */
  463. static struct dentry *ecryptfs_mount(struct file_system_type *fs_type, int flags,
  464. const char *dev_name, void *raw_data)
  465. {
  466. struct super_block *s;
  467. struct ecryptfs_sb_info *sbi;
  468. struct ecryptfs_dentry_info *root_info;
  469. const char *err = "Getting sb failed";
  470. struct inode *inode;
  471. struct path path;
  472. uid_t check_ruid;
  473. int rc;
  474. sbi = kmem_cache_zalloc(ecryptfs_sb_info_cache, GFP_KERNEL);
  475. if (!sbi) {
  476. rc = -ENOMEM;
  477. goto out;
  478. }
  479. rc = ecryptfs_parse_options(sbi, raw_data, &check_ruid);
  480. if (rc) {
  481. err = "Error parsing options";
  482. goto out;
  483. }
  484. s = sget(fs_type, NULL, set_anon_super, flags, NULL);
  485. if (IS_ERR(s)) {
  486. rc = PTR_ERR(s);
  487. goto out;
  488. }
  489. rc = bdi_setup_and_register(&sbi->bdi, "ecryptfs", BDI_CAP_MAP_COPY);
  490. if (rc)
  491. goto out1;
  492. ecryptfs_set_superblock_private(s, sbi);
  493. s->s_bdi = &sbi->bdi;
  494. /* ->kill_sb() will take care of sbi after that point */
  495. sbi = NULL;
  496. s->s_op = &ecryptfs_sops;
  497. s->s_d_op = &ecryptfs_dops;
  498. err = "Reading sb failed";
  499. rc = kern_path(dev_name, LOOKUP_FOLLOW | LOOKUP_DIRECTORY, &path);
  500. if (rc) {
  501. ecryptfs_printk(KERN_WARNING, "kern_path() failed\n");
  502. goto out1;
  503. }
  504. if (path.dentry->d_sb->s_type == &ecryptfs_fs_type) {
  505. rc = -EINVAL;
  506. printk(KERN_ERR "Mount on filesystem of type "
  507. "eCryptfs explicitly disallowed due to "
  508. "known incompatibilities\n");
  509. goto out_free;
  510. }
  511. if (check_ruid && !uid_eq(path.dentry->d_inode->i_uid, current_uid())) {
  512. rc = -EPERM;
  513. printk(KERN_ERR "Mount of device (uid: %d) not owned by "
  514. "requested user (uid: %d)\n",
  515. i_uid_read(path.dentry->d_inode),
  516. from_kuid(&init_user_ns, current_uid()));
  517. goto out_free;
  518. }
  519. ecryptfs_set_superblock_lower(s, path.dentry->d_sb);
  520. /**
  521. * Set the POSIX ACL flag based on whether they're enabled in the lower
  522. * mount. Force a read-only eCryptfs mount if the lower mount is ro.
  523. * Allow a ro eCryptfs mount even when the lower mount is rw.
  524. */
  525. s->s_flags = flags & ~MS_POSIXACL;
  526. s->s_flags |= path.dentry->d_sb->s_flags & (MS_RDONLY | MS_POSIXACL);
  527. s->s_maxbytes = path.dentry->d_sb->s_maxbytes;
  528. s->s_blocksize = path.dentry->d_sb->s_blocksize;
  529. s->s_magic = ECRYPTFS_SUPER_MAGIC;
  530. inode = ecryptfs_get_inode(path.dentry->d_inode, s);
  531. rc = PTR_ERR(inode);
  532. if (IS_ERR(inode))
  533. goto out_free;
  534. s->s_root = d_make_root(inode);
  535. if (!s->s_root) {
  536. rc = -ENOMEM;
  537. goto out_free;
  538. }
  539. rc = -ENOMEM;
  540. root_info = kmem_cache_zalloc(ecryptfs_dentry_info_cache, GFP_KERNEL);
  541. if (!root_info)
  542. goto out_free;
  543. /* ->kill_sb() will take care of root_info */
  544. ecryptfs_set_dentry_private(s->s_root, root_info);
  545. ecryptfs_set_dentry_lower(s->s_root, path.dentry);
  546. ecryptfs_set_dentry_lower_mnt(s->s_root, path.mnt);
  547. s->s_flags |= MS_ACTIVE;
  548. return dget(s->s_root);
  549. out_free:
  550. path_put(&path);
  551. out1:
  552. deactivate_locked_super(s);
  553. out:
  554. if (sbi) {
  555. ecryptfs_destroy_mount_crypt_stat(&sbi->mount_crypt_stat);
  556. kmem_cache_free(ecryptfs_sb_info_cache, sbi);
  557. }
  558. printk(KERN_ERR "%s; rc = [%d]\n", err, rc);
  559. return ERR_PTR(rc);
  560. }
  561. /**
  562. * ecryptfs_kill_block_super
  563. * @sb: The ecryptfs super block
  564. *
  565. * Used to bring the superblock down and free the private data.
  566. */
  567. static void ecryptfs_kill_block_super(struct super_block *sb)
  568. {
  569. struct ecryptfs_sb_info *sb_info = ecryptfs_superblock_to_private(sb);
  570. kill_anon_super(sb);
  571. if (!sb_info)
  572. return;
  573. ecryptfs_destroy_mount_crypt_stat(&sb_info->mount_crypt_stat);
  574. bdi_destroy(&sb_info->bdi);
  575. kmem_cache_free(ecryptfs_sb_info_cache, sb_info);
  576. }
  577. static struct file_system_type ecryptfs_fs_type = {
  578. .owner = THIS_MODULE,
  579. .name = "ecryptfs",
  580. .mount = ecryptfs_mount,
  581. .kill_sb = ecryptfs_kill_block_super,
  582. .fs_flags = 0
  583. };
  584. MODULE_ALIAS_FS("ecryptfs");
  585. /**
  586. * inode_info_init_once
  587. *
  588. * Initializes the ecryptfs_inode_info_cache when it is created
  589. */
  590. static void
  591. inode_info_init_once(void *vptr)
  592. {
  593. struct ecryptfs_inode_info *ei = (struct ecryptfs_inode_info *)vptr;
  594. inode_init_once(&ei->vfs_inode);
  595. }
  596. static struct ecryptfs_cache_info {
  597. struct kmem_cache **cache;
  598. const char *name;
  599. size_t size;
  600. void (*ctor)(void *obj);
  601. } ecryptfs_cache_infos[] = {
  602. {
  603. .cache = &ecryptfs_auth_tok_list_item_cache,
  604. .name = "ecryptfs_auth_tok_list_item",
  605. .size = sizeof(struct ecryptfs_auth_tok_list_item),
  606. },
  607. {
  608. .cache = &ecryptfs_file_info_cache,
  609. .name = "ecryptfs_file_cache",
  610. .size = sizeof(struct ecryptfs_file_info),
  611. },
  612. {
  613. .cache = &ecryptfs_dentry_info_cache,
  614. .name = "ecryptfs_dentry_info_cache",
  615. .size = sizeof(struct ecryptfs_dentry_info),
  616. },
  617. {
  618. .cache = &ecryptfs_inode_info_cache,
  619. .name = "ecryptfs_inode_cache",
  620. .size = sizeof(struct ecryptfs_inode_info),
  621. .ctor = inode_info_init_once,
  622. },
  623. {
  624. .cache = &ecryptfs_sb_info_cache,
  625. .name = "ecryptfs_sb_cache",
  626. .size = sizeof(struct ecryptfs_sb_info),
  627. },
  628. {
  629. .cache = &ecryptfs_header_cache,
  630. .name = "ecryptfs_headers",
  631. .size = PAGE_CACHE_SIZE,
  632. },
  633. {
  634. .cache = &ecryptfs_xattr_cache,
  635. .name = "ecryptfs_xattr_cache",
  636. .size = PAGE_CACHE_SIZE,
  637. },
  638. {
  639. .cache = &ecryptfs_key_record_cache,
  640. .name = "ecryptfs_key_record_cache",
  641. .size = sizeof(struct ecryptfs_key_record),
  642. },
  643. {
  644. .cache = &ecryptfs_key_sig_cache,
  645. .name = "ecryptfs_key_sig_cache",
  646. .size = sizeof(struct ecryptfs_key_sig),
  647. },
  648. {
  649. .cache = &ecryptfs_global_auth_tok_cache,
  650. .name = "ecryptfs_global_auth_tok_cache",
  651. .size = sizeof(struct ecryptfs_global_auth_tok),
  652. },
  653. {
  654. .cache = &ecryptfs_key_tfm_cache,
  655. .name = "ecryptfs_key_tfm_cache",
  656. .size = sizeof(struct ecryptfs_key_tfm),
  657. },
  658. };
  659. static void ecryptfs_free_kmem_caches(void)
  660. {
  661. int i;
  662. /*
  663. * Make sure all delayed rcu free inodes are flushed before we
  664. * destroy cache.
  665. */
  666. rcu_barrier();
  667. for (i = 0; i < ARRAY_SIZE(ecryptfs_cache_infos); i++) {
  668. struct ecryptfs_cache_info *info;
  669. info = &ecryptfs_cache_infos[i];
  670. if (*(info->cache))
  671. kmem_cache_destroy(*(info->cache));
  672. }
  673. }
  674. /**
  675. * ecryptfs_init_kmem_caches
  676. *
  677. * Returns zero on success; non-zero otherwise
  678. */
  679. static int ecryptfs_init_kmem_caches(void)
  680. {
  681. int i;
  682. for (i = 0; i < ARRAY_SIZE(ecryptfs_cache_infos); i++) {
  683. struct ecryptfs_cache_info *info;
  684. info = &ecryptfs_cache_infos[i];
  685. *(info->cache) = kmem_cache_create(info->name, info->size,
  686. 0, SLAB_HWCACHE_ALIGN, info->ctor);
  687. if (!*(info->cache)) {
  688. ecryptfs_free_kmem_caches();
  689. ecryptfs_printk(KERN_WARNING, "%s: "
  690. "kmem_cache_create failed\n",
  691. info->name);
  692. return -ENOMEM;
  693. }
  694. }
  695. return 0;
  696. }
  697. static struct kobject *ecryptfs_kobj;
  698. static ssize_t version_show(struct kobject *kobj,
  699. struct kobj_attribute *attr, char *buff)
  700. {
  701. return snprintf(buff, PAGE_SIZE, "%d\n", ECRYPTFS_VERSIONING_MASK);
  702. }
  703. static struct kobj_attribute version_attr = __ATTR_RO(version);
  704. static struct attribute *attributes[] = {
  705. &version_attr.attr,
  706. NULL,
  707. };
  708. static struct attribute_group attr_group = {
  709. .attrs = attributes,
  710. };
  711. static int do_sysfs_registration(void)
  712. {
  713. int rc;
  714. ecryptfs_kobj = kobject_create_and_add("ecryptfs", fs_kobj);
  715. if (!ecryptfs_kobj) {
  716. printk(KERN_ERR "Unable to create ecryptfs kset\n");
  717. rc = -ENOMEM;
  718. goto out;
  719. }
  720. rc = sysfs_create_group(ecryptfs_kobj, &attr_group);
  721. if (rc) {
  722. printk(KERN_ERR
  723. "Unable to create ecryptfs version attributes\n");
  724. kobject_put(ecryptfs_kobj);
  725. }
  726. out:
  727. return rc;
  728. }
  729. static void do_sysfs_unregistration(void)
  730. {
  731. sysfs_remove_group(ecryptfs_kobj, &attr_group);
  732. kobject_put(ecryptfs_kobj);
  733. }
  734. static int __init ecryptfs_init(void)
  735. {
  736. int rc;
  737. if (ECRYPTFS_DEFAULT_EXTENT_SIZE > PAGE_CACHE_SIZE) {
  738. rc = -EINVAL;
  739. ecryptfs_printk(KERN_ERR, "The eCryptfs extent size is "
  740. "larger than the host's page size, and so "
  741. "eCryptfs cannot run on this system. The "
  742. "default eCryptfs extent size is [%u] bytes; "
  743. "the page size is [%lu] bytes.\n",
  744. ECRYPTFS_DEFAULT_EXTENT_SIZE,
  745. (unsigned long)PAGE_CACHE_SIZE);
  746. goto out;
  747. }
  748. rc = ecryptfs_init_kmem_caches();
  749. if (rc) {
  750. printk(KERN_ERR
  751. "Failed to allocate one or more kmem_cache objects\n");
  752. goto out;
  753. }
  754. rc = do_sysfs_registration();
  755. if (rc) {
  756. printk(KERN_ERR "sysfs registration failed\n");
  757. goto out_free_kmem_caches;
  758. }
  759. rc = ecryptfs_init_kthread();
  760. if (rc) {
  761. printk(KERN_ERR "%s: kthread initialization failed; "
  762. "rc = [%d]\n", __func__, rc);
  763. goto out_do_sysfs_unregistration;
  764. }
  765. rc = ecryptfs_init_messaging();
  766. if (rc) {
  767. printk(KERN_ERR "Failure occurred while attempting to "
  768. "initialize the communications channel to "
  769. "ecryptfsd\n");
  770. goto out_destroy_kthread;
  771. }
  772. rc = ecryptfs_init_crypto();
  773. if (rc) {
  774. printk(KERN_ERR "Failure whilst attempting to init crypto; "
  775. "rc = [%d]\n", rc);
  776. goto out_release_messaging;
  777. }
  778. rc = register_filesystem(&ecryptfs_fs_type);
  779. if (rc) {
  780. printk(KERN_ERR "Failed to register filesystem\n");
  781. goto out_destroy_crypto;
  782. }
  783. if (ecryptfs_verbosity > 0)
  784. printk(KERN_CRIT "eCryptfs verbosity set to %d. Secret values "
  785. "will be written to the syslog!\n", ecryptfs_verbosity);
  786. goto out;
  787. out_destroy_crypto:
  788. ecryptfs_destroy_crypto();
  789. out_release_messaging:
  790. ecryptfs_release_messaging();
  791. out_destroy_kthread:
  792. ecryptfs_destroy_kthread();
  793. out_do_sysfs_unregistration:
  794. do_sysfs_unregistration();
  795. out_free_kmem_caches:
  796. ecryptfs_free_kmem_caches();
  797. out:
  798. return rc;
  799. }
  800. static void __exit ecryptfs_exit(void)
  801. {
  802. int rc;
  803. rc = ecryptfs_destroy_crypto();
  804. if (rc)
  805. printk(KERN_ERR "Failure whilst attempting to destroy crypto; "
  806. "rc = [%d]\n", rc);
  807. ecryptfs_release_messaging();
  808. ecryptfs_destroy_kthread();
  809. do_sysfs_unregistration();
  810. unregister_filesystem(&ecryptfs_fs_type);
  811. ecryptfs_free_kmem_caches();
  812. }
  813. MODULE_AUTHOR("Michael A. Halcrow <mhalcrow@us.ibm.com>");
  814. MODULE_DESCRIPTION("eCryptfs");
  815. MODULE_LICENSE("GPL");
  816. module_init(ecryptfs_init)
  817. module_exit(ecryptfs_exit)