diff options
| author | Eric Biggers <ebiggers@google.com> | 2016-12-05 22:12:44 +0300 |
|---|---|---|
| committer | Theodore Ts'o <tytso@mit.edu> | 2017-01-01 00:26:20 +0300 |
| commit | 54475f531bb8d7078f63c159e5e0615d486c498c (patch) | |
| tree | ce3392249747414ad787dcffa1f2b919aff5f10c /fs/ext4/namei.c | |
| parent | 42d97eb0ade31e1bc537d086842f5d6e766d9d51 (diff) | |
| download | linux-54475f531bb8d7078f63c159e5e0615d486c498c.tar.xz | |
fscrypt: use ENOKEY when file cannot be created w/o key
As part of an effort to clean up fscrypt-related error codes, make
attempting to create a file in an encrypted directory that hasn't been
"unlocked" fail with ENOKEY. Previously, several error codes were used
for this case, including ENOENT, EACCES, and EPERM, and they were not
consistent between and within filesystems. ENOKEY is a better choice
because it expresses that the failure is due to lacking the encryption
key. It also matches the error code returned when trying to open an
encrypted regular file without the key.
I am not aware of any users who might be relying on the previous
inconsistent error codes, which were never documented anywhere.
This failure case will be exercised by an xfstest.
Signed-off-by: Eric Biggers <ebiggers@google.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Diffstat (limited to 'fs/ext4/namei.c')
| -rw-r--r-- | fs/ext4/namei.c | 4 |
1 files changed, 3 insertions, 1 deletions
diff --git a/fs/ext4/namei.c b/fs/ext4/namei.c index eadba919f26b..80b8afa4a8f9 100644 --- a/fs/ext4/namei.c +++ b/fs/ext4/namei.c @@ -1378,6 +1378,8 @@ static struct buffer_head * ext4_find_entry (struct inode *dir, return NULL; retval = ext4_fname_setup_filename(dir, d_name, 1, &fname); + if (retval == -ENOENT) + return NULL; if (retval) return ERR_PTR(retval); @@ -3088,7 +3090,7 @@ static int ext4_symlink(struct inode *dir, if (err) return err; if (!fscrypt_has_encryption_key(dir)) - return -EPERM; + return -ENOKEY; disk_link.len = (fscrypt_fname_encrypted_size(dir, len) + sizeof(struct fscrypt_symlink_data)); sd = kzalloc(disk_link.len, GFP_KERNEL); |