From: Eric Biggers <ebiggers@kernel.org>
To: "Theodore Y. Ts'o" <tytso@mit.edu>
Cc: linux-fscrypt@vger.kernel.org, linux-fsdevel@vger.kernel.org,
linux-ext4@vger.kernel.org,
linux-f2fs-devel@lists.sourceforge.net,
linux-mtd@lists.infradead.org, linux-api@vger.kernel.org,
linux-crypto@vger.kernel.org, keyrings@vger.kernel.org,
Paul Crowley <paulcrowley@google.com>,
Satya Tangirala <satyat@google.com>
Subject: Re: [PATCH v7 10/16] fscrypt: v2 encryption policy support
Date: Mon, 29 Jul 2019 13:46:28 -0700 [thread overview]
Message-ID: <20190729204627.GH169027@gmail.com> (raw)
In-Reply-To: <20190728211730.GK6088@mit.edu>
On Sun, Jul 28, 2019 at 05:17:30PM -0400, Theodore Y. Ts'o wrote:
> On Fri, Jul 26, 2019 at 03:41:35PM -0700, Eric Biggers wrote:
> > @@ -319,6 +329,31 @@ int fscrypt_ioctl_add_key(struct file *filp, void __user *_uarg)
> > if (!capable(CAP_SYS_ADMIN))
> > goto out_wipe_secret;
> >
> > + if (arg.key_spec.type != FSCRYPT_KEY_SPEC_TYPE_DESCRIPTOR) {
>
> This should be "== FSCRYPT_KEY_SPEC_TYPE_INDENTIFIER" instead. That's
> because you use the identifier part of the union:
>
> > + /* Calculate the key identifier and return it to userspace. */
> > + err = fscrypt_hkdf_expand(&secret.hkdf,
> > + HKDF_CONTEXT_KEY_IDENTIFIER,
> > + NULL, 0, arg.key_spec.u.identifier,
>
> If we ever add a new key specifier type, and alternative in the union,
> this is going to come back to bite us.
Well, I did it this way because the next patch changes the code to:
if (arg.key_spec.type == FSCRYPT_KEY_SPEC_TYPE_DESCRIPTOR) {
...
} else {
...
}
We already validated that it's either TYPE_DESCRIPTOR or TYPE_IDENTIFIER.
But I guess to be more clear I'll just make it handle the default case again.
switch (arg.key_spec.type) {
case FSCRYPT_KEY_SPEC_TYPE_DESCRIPTOR:
...
break;
case FSCRYPT_KEY_SPEC_TYPE_IDENTIFIER:
...
break;
default:
err = -EINVAL;
break;
}
>
> > + if (policy->version == FSCRYPT_POLICY_V1) {
> > + /*
> > + * The original encryption policy version provided no way of
> > + * verifying that the correct master key was supplied, which was
> > + * insecure in scenarios where multiple users have access to the
> > + * same encrypted files (even just read-only access).
>
> Which scenario do you have in mind? With read-only access, Alice can
> fetch the encryption policy for a directory, and introduce a key with
> the same descriptor, but the "wrong" key, but that's only going to
> affect Alice's use of the key. It won't affect what key is used by
> Bob, since Alice doesn't have write access to Bob's keyrings.
>
> If what you mean is the risk when there is a single global
> filesystem-specific keyring, where Alice could introduce a "wrong" key
> identified with a specific descriptor, then sure, Alice could trick
> Bob into encrypting his data with the wrong key (one known to Alice).
> But we don't allow keys usable by V1 policies to be used in the
> filesystem-specific keyring, do we?
>
The scenario is that Alice lists the directory with the wrong key, then Bob
lists the directory too and gets the wrong filenames. This happens because the
inode, fscrypt_info, dentry cache, page cache, etc. are the same for everyone.
Bob's key is never looked up because the inode already has a key cached.
This also applies to regular files and symlinks.
- Eric
WARNING: multiple messages have this Message-ID (diff)
From: Eric Biggers <ebiggers@kernel.org>
To: "Theodore Y. Ts'o" <tytso@mit.edu>
Cc: Satya Tangirala <satyat@google.com>,
linux-api@vger.kernel.org,
linux-f2fs-devel@lists.sourceforge.net,
linux-fscrypt@vger.kernel.org, keyrings@vger.kernel.org,
linux-mtd@lists.infradead.org, linux-crypto@vger.kernel.org,
linux-fsdevel@vger.kernel.org, linux-ext4@vger.kernel.org,
Paul Crowley <paulcrowley@google.com>
Subject: Re: [PATCH v7 10/16] fscrypt: v2 encryption policy support
Date: Mon, 29 Jul 2019 20:46:28 +0000 [thread overview]
Message-ID: <20190729204627.GH169027@gmail.com> (raw)
In-Reply-To: <20190728211730.GK6088@mit.edu>
On Sun, Jul 28, 2019 at 05:17:30PM -0400, Theodore Y. Ts'o wrote:
> On Fri, Jul 26, 2019 at 03:41:35PM -0700, Eric Biggers wrote:
> > @@ -319,6 +329,31 @@ int fscrypt_ioctl_add_key(struct file *filp, void __user *_uarg)
> > if (!capable(CAP_SYS_ADMIN))
> > goto out_wipe_secret;
> >
> > + if (arg.key_spec.type != FSCRYPT_KEY_SPEC_TYPE_DESCRIPTOR) {
>
> This should be "= FSCRYPT_KEY_SPEC_TYPE_INDENTIFIER" instead. That's
> because you use the identifier part of the union:
>
> > + /* Calculate the key identifier and return it to userspace. */
> > + err = fscrypt_hkdf_expand(&secret.hkdf,
> > + HKDF_CONTEXT_KEY_IDENTIFIER,
> > + NULL, 0, arg.key_spec.u.identifier,
>
> If we ever add a new key specifier type, and alternative in the union,
> this is going to come back to bite us.
Well, I did it this way because the next patch changes the code to:
if (arg.key_spec.type = FSCRYPT_KEY_SPEC_TYPE_DESCRIPTOR) {
...
} else {
...
}
We already validated that it's either TYPE_DESCRIPTOR or TYPE_IDENTIFIER.
But I guess to be more clear I'll just make it handle the default case again.
switch (arg.key_spec.type) {
case FSCRYPT_KEY_SPEC_TYPE_DESCRIPTOR:
...
break;
case FSCRYPT_KEY_SPEC_TYPE_IDENTIFIER:
...
break;
default:
err = -EINVAL;
break;
}
>
> > + if (policy->version = FSCRYPT_POLICY_V1) {
> > + /*
> > + * The original encryption policy version provided no way of
> > + * verifying that the correct master key was supplied, which was
> > + * insecure in scenarios where multiple users have access to the
> > + * same encrypted files (even just read-only access).
>
> Which scenario do you have in mind? With read-only access, Alice can
> fetch the encryption policy for a directory, and introduce a key with
> the same descriptor, but the "wrong" key, but that's only going to
> affect Alice's use of the key. It won't affect what key is used by
> Bob, since Alice doesn't have write access to Bob's keyrings.
>
> If what you mean is the risk when there is a single global
> filesystem-specific keyring, where Alice could introduce a "wrong" key
> identified with a specific descriptor, then sure, Alice could trick
> Bob into encrypting his data with the wrong key (one known to Alice).
> But we don't allow keys usable by V1 policies to be used in the
> filesystem-specific keyring, do we?
>
The scenario is that Alice lists the directory with the wrong key, then Bob
lists the directory too and gets the wrong filenames. This happens because the
inode, fscrypt_info, dentry cache, page cache, etc. are the same for everyone.
Bob's key is never looked up because the inode already has a key cached.
This also applies to regular files and symlinks.
- Eric
WARNING: multiple messages have this Message-ID (diff)
From: Eric Biggers <ebiggers@kernel.org>
To: "Theodore Y. Ts'o" <tytso@mit.edu>
Cc: Satya Tangirala <satyat@google.com>,
linux-api@vger.kernel.org,
linux-f2fs-devel@lists.sourceforge.net,
linux-fscrypt@vger.kernel.org, keyrings@vger.kernel.org,
linux-mtd@lists.infradead.org, linux-crypto@vger.kernel.org,
linux-fsdevel@vger.kernel.org, linux-ext4@vger.kernel.org,
Paul Crowley <paulcrowley@google.com>
Subject: Re: [PATCH v7 10/16] fscrypt: v2 encryption policy support
Date: Mon, 29 Jul 2019 13:46:28 -0700 [thread overview]
Message-ID: <20190729204627.GH169027@gmail.com> (raw)
In-Reply-To: <20190728211730.GK6088@mit.edu>
On Sun, Jul 28, 2019 at 05:17:30PM -0400, Theodore Y. Ts'o wrote:
> On Fri, Jul 26, 2019 at 03:41:35PM -0700, Eric Biggers wrote:
> > @@ -319,6 +329,31 @@ int fscrypt_ioctl_add_key(struct file *filp, void __user *_uarg)
> > if (!capable(CAP_SYS_ADMIN))
> > goto out_wipe_secret;
> >
> > + if (arg.key_spec.type != FSCRYPT_KEY_SPEC_TYPE_DESCRIPTOR) {
>
> This should be "== FSCRYPT_KEY_SPEC_TYPE_INDENTIFIER" instead. That's
> because you use the identifier part of the union:
>
> > + /* Calculate the key identifier and return it to userspace. */
> > + err = fscrypt_hkdf_expand(&secret.hkdf,
> > + HKDF_CONTEXT_KEY_IDENTIFIER,
> > + NULL, 0, arg.key_spec.u.identifier,
>
> If we ever add a new key specifier type, and alternative in the union,
> this is going to come back to bite us.
Well, I did it this way because the next patch changes the code to:
if (arg.key_spec.type == FSCRYPT_KEY_SPEC_TYPE_DESCRIPTOR) {
...
} else {
...
}
We already validated that it's either TYPE_DESCRIPTOR or TYPE_IDENTIFIER.
But I guess to be more clear I'll just make it handle the default case again.
switch (arg.key_spec.type) {
case FSCRYPT_KEY_SPEC_TYPE_DESCRIPTOR:
...
break;
case FSCRYPT_KEY_SPEC_TYPE_IDENTIFIER:
...
break;
default:
err = -EINVAL;
break;
}
>
> > + if (policy->version == FSCRYPT_POLICY_V1) {
> > + /*
> > + * The original encryption policy version provided no way of
> > + * verifying that the correct master key was supplied, which was
> > + * insecure in scenarios where multiple users have access to the
> > + * same encrypted files (even just read-only access).
>
> Which scenario do you have in mind? With read-only access, Alice can
> fetch the encryption policy for a directory, and introduce a key with
> the same descriptor, but the "wrong" key, but that's only going to
> affect Alice's use of the key. It won't affect what key is used by
> Bob, since Alice doesn't have write access to Bob's keyrings.
>
> If what you mean is the risk when there is a single global
> filesystem-specific keyring, where Alice could introduce a "wrong" key
> identified with a specific descriptor, then sure, Alice could trick
> Bob into encrypting his data with the wrong key (one known to Alice).
> But we don't allow keys usable by V1 policies to be used in the
> filesystem-specific keyring, do we?
>
The scenario is that Alice lists the directory with the wrong key, then Bob
lists the directory too and gets the wrong filenames. This happens because the
inode, fscrypt_info, dentry cache, page cache, etc. are the same for everyone.
Bob's key is never looked up because the inode already has a key cached.
This also applies to regular files and symlinks.
- Eric
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
WARNING: multiple messages have this Message-ID (diff)
From: Eric Biggers <ebiggers@kernel.org>
To: "Theodore Y. Ts'o" <tytso@mit.edu>
Cc: Satya Tangirala <satyat@google.com>,
linux-api@vger.kernel.org,
linux-f2fs-devel@lists.sourceforge.net,
linux-fscrypt@vger.kernel.org, keyrings@vger.kernel.org,
linux-mtd@lists.infradead.org, linux-crypto@vger.kernel.org,
linux-fsdevel@vger.kernel.org, linux-ext4@vger.kernel.org,
Paul Crowley <paulcrowley@google.com>
Subject: Re: [f2fs-dev] [PATCH v7 10/16] fscrypt: v2 encryption policy support
Date: Mon, 29 Jul 2019 13:46:28 -0700 [thread overview]
Message-ID: <20190729204627.GH169027@gmail.com> (raw)
In-Reply-To: <20190728211730.GK6088@mit.edu>
On Sun, Jul 28, 2019 at 05:17:30PM -0400, Theodore Y. Ts'o wrote:
> On Fri, Jul 26, 2019 at 03:41:35PM -0700, Eric Biggers wrote:
> > @@ -319,6 +329,31 @@ int fscrypt_ioctl_add_key(struct file *filp, void __user *_uarg)
> > if (!capable(CAP_SYS_ADMIN))
> > goto out_wipe_secret;
> >
> > + if (arg.key_spec.type != FSCRYPT_KEY_SPEC_TYPE_DESCRIPTOR) {
>
> This should be "== FSCRYPT_KEY_SPEC_TYPE_INDENTIFIER" instead. That's
> because you use the identifier part of the union:
>
> > + /* Calculate the key identifier and return it to userspace. */
> > + err = fscrypt_hkdf_expand(&secret.hkdf,
> > + HKDF_CONTEXT_KEY_IDENTIFIER,
> > + NULL, 0, arg.key_spec.u.identifier,
>
> If we ever add a new key specifier type, and alternative in the union,
> this is going to come back to bite us.
Well, I did it this way because the next patch changes the code to:
if (arg.key_spec.type == FSCRYPT_KEY_SPEC_TYPE_DESCRIPTOR) {
...
} else {
...
}
We already validated that it's either TYPE_DESCRIPTOR or TYPE_IDENTIFIER.
But I guess to be more clear I'll just make it handle the default case again.
switch (arg.key_spec.type) {
case FSCRYPT_KEY_SPEC_TYPE_DESCRIPTOR:
...
break;
case FSCRYPT_KEY_SPEC_TYPE_IDENTIFIER:
...
break;
default:
err = -EINVAL;
break;
}
>
> > + if (policy->version == FSCRYPT_POLICY_V1) {
> > + /*
> > + * The original encryption policy version provided no way of
> > + * verifying that the correct master key was supplied, which was
> > + * insecure in scenarios where multiple users have access to the
> > + * same encrypted files (even just read-only access).
>
> Which scenario do you have in mind? With read-only access, Alice can
> fetch the encryption policy for a directory, and introduce a key with
> the same descriptor, but the "wrong" key, but that's only going to
> affect Alice's use of the key. It won't affect what key is used by
> Bob, since Alice doesn't have write access to Bob's keyrings.
>
> If what you mean is the risk when there is a single global
> filesystem-specific keyring, where Alice could introduce a "wrong" key
> identified with a specific descriptor, then sure, Alice could trick
> Bob into encrypting his data with the wrong key (one known to Alice).
> But we don't allow keys usable by V1 policies to be used in the
> filesystem-specific keyring, do we?
>
The scenario is that Alice lists the directory with the wrong key, then Bob
lists the directory too and gets the wrong filenames. This happens because the
inode, fscrypt_info, dentry cache, page cache, etc. are the same for everyone.
Bob's key is never looked up because the inode already has a key cached.
This also applies to regular files and symlinks.
- Eric
_______________________________________________
Linux-f2fs-devel mailing list
Linux-f2fs-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
next prev parent reply other threads:[~2019-07-29 20:46 UTC|newest]
Thread overview: 230+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-07-26 22:41 [PATCH v7 00/16] fscrypt: key management improvements Eric Biggers
2019-07-26 22:41 ` Eric Biggers
2019-07-26 22:41 ` Eric Biggers
2019-07-26 22:41 ` Eric Biggers
2019-07-26 22:41 ` [f2fs-dev] " Eric Biggers
2019-07-26 22:41 ` [PATCH v7 01/16] fs, fscrypt: move uapi definitions to new header <linux/fscrypt.h> Eric Biggers
2019-07-26 22:41 ` Eric Biggers
2019-07-26 22:41 ` Eric Biggers
2019-07-26 22:41 ` [f2fs-dev] " Eric Biggers
2019-07-28 15:08 ` Theodore Y. Ts'o
2019-07-28 15:08 ` Theodore Y. Ts'o
2019-07-28 15:08 ` [f2fs-dev] " Theodore Y. Ts'o
2019-07-28 15:08 ` Theodore Y. Ts'o
2019-07-28 15:08 ` Theodore Y. Ts'o
2019-07-26 22:41 ` [PATCH v7 02/16] fscrypt: use FSCRYPT_ prefix for uapi constants Eric Biggers
2019-07-26 22:41 ` Eric Biggers
2019-07-26 22:41 ` Eric Biggers
2019-07-26 22:41 ` Eric Biggers
2019-07-26 22:41 ` [f2fs-dev] " Eric Biggers
2019-07-26 22:41 ` [PATCH v7 03/16] fscrypt: use FSCRYPT_* definitions, not FS_* Eric Biggers
2019-07-26 22:41 ` Eric Biggers
2019-07-26 22:41 ` Eric Biggers
2019-07-26 22:41 ` Eric Biggers
2019-07-26 22:41 ` [f2fs-dev] " Eric Biggers
2019-07-26 22:41 ` [PATCH v7 04/16] fscrypt: add ->ci_inode to fscrypt_info Eric Biggers
2019-07-26 22:41 ` Eric Biggers
2019-07-26 22:41 ` Eric Biggers
2019-07-26 22:41 ` Eric Biggers
2019-07-26 22:41 ` [f2fs-dev] " Eric Biggers
2019-07-28 15:09 ` Theodore Y. Ts'o
2019-07-28 15:09 ` [f2fs-dev] " Theodore Y. Ts'o
2019-07-28 15:09 ` Theodore Y. Ts'o
2019-07-28 15:09 ` Theodore Y. Ts'o
2019-07-26 22:41 ` [PATCH v7 05/16] fscrypt: refactor v1 policy key setup into keysetup_legacy.c Eric Biggers
2019-07-26 22:41 ` Eric Biggers
2019-07-26 22:41 ` Eric Biggers
2019-07-26 22:41 ` Eric Biggers
2019-07-26 22:41 ` [f2fs-dev] " Eric Biggers
2019-07-28 15:40 ` Theodore Y. Ts'o
2019-07-28 15:40 ` [f2fs-dev] " Theodore Y. Ts'o
2019-07-28 15:40 ` Theodore Y. Ts'o
2019-07-28 15:40 ` Theodore Y. Ts'o
2019-07-29 19:37 ` Eric Biggers
2019-07-29 19:37 ` Eric Biggers
2019-07-29 19:37 ` Eric Biggers
2019-07-29 19:37 ` [f2fs-dev] " Eric Biggers
2019-07-26 22:41 ` [PATCH v7 06/16] fscrypt: add FS_IOC_ADD_ENCRYPTION_KEY ioctl Eric Biggers
2019-07-26 22:41 ` Eric Biggers
2019-07-26 22:41 ` Eric Biggers
2019-07-26 22:41 ` Eric Biggers
2019-07-26 22:41 ` [f2fs-dev] " Eric Biggers
2019-07-28 18:50 ` Theodore Y. Ts'o
2019-07-28 18:50 ` [f2fs-dev] " Theodore Y. Ts'o
2019-07-28 18:50 ` Theodore Y. Ts'o
2019-07-28 18:50 ` Theodore Y. Ts'o
2019-07-29 19:46 ` Eric Biggers
2019-07-29 19:46 ` Eric Biggers
2019-07-29 19:46 ` Eric Biggers
2019-07-29 19:46 ` Eric Biggers
2019-07-29 19:46 ` [f2fs-dev] " Eric Biggers
2019-07-29 20:14 ` Theodore Y. Ts'o
2019-07-29 20:14 ` Theodore Y. Ts'o
2019-07-29 20:14 ` Theodore Y. Ts'o
2019-07-29 20:14 ` [f2fs-dev] " Theodore Y. Ts'o
2019-07-26 22:41 ` [PATCH v7 07/16] fscrypt: add FS_IOC_REMOVE_ENCRYPTION_KEY ioctl Eric Biggers
2019-07-26 22:41 ` Eric Biggers
2019-07-26 22:41 ` Eric Biggers
2019-07-26 22:41 ` Eric Biggers
2019-07-26 22:41 ` [f2fs-dev] " Eric Biggers
2019-07-28 19:24 ` Theodore Y. Ts'o
2019-07-28 19:24 ` [f2fs-dev] " Theodore Y. Ts'o
2019-07-28 19:24 ` Theodore Y. Ts'o
2019-07-28 19:24 ` Theodore Y. Ts'o
2019-07-29 19:58 ` Eric Biggers
2019-07-29 19:58 ` Eric Biggers
2019-07-29 19:58 ` Eric Biggers
2019-07-29 19:58 ` Eric Biggers
2019-07-29 19:58 ` [f2fs-dev] " Eric Biggers
2019-07-31 18:38 ` Eric Biggers
2019-07-31 18:38 ` Eric Biggers
2019-07-31 18:38 ` Eric Biggers
2019-07-31 18:38 ` [f2fs-dev] " Eric Biggers
2019-07-31 23:38 ` Theodore Y. Ts'o
2019-07-31 23:38 ` Theodore Y. Ts'o
2019-07-31 23:38 ` Theodore Y. Ts'o
2019-07-31 23:38 ` [f2fs-dev] " Theodore Y. Ts'o
2019-08-01 1:11 ` Eric Biggers
2019-08-01 1:11 ` Eric Biggers
2019-08-01 1:11 ` Eric Biggers
2019-08-01 1:11 ` [f2fs-dev] " Eric Biggers
2019-08-01 1:11 ` Eric Biggers
2019-08-01 5:31 ` Theodore Y. Ts'o
2019-08-01 5:31 ` Theodore Y. Ts'o
2019-08-01 5:31 ` Theodore Y. Ts'o
2019-08-01 5:31 ` Theodore Y. Ts'o
2019-08-01 18:35 ` Eric Biggers
2019-08-01 18:35 ` Eric Biggers
2019-08-01 18:35 ` Eric Biggers
2019-08-01 18:35 ` Eric Biggers
2019-08-01 18:35 ` [f2fs-dev] " Eric Biggers
2019-08-01 18:46 ` Eric Biggers
2019-08-01 18:46 ` Eric Biggers
2019-08-01 18:46 ` Eric Biggers
2019-08-01 18:46 ` [f2fs-dev] " Eric Biggers
2019-08-01 22:04 ` Eric Biggers
2019-08-01 22:04 ` Eric Biggers
2019-08-01 22:04 ` Eric Biggers
2019-08-01 22:04 ` [f2fs-dev] " Eric Biggers
2019-08-02 4:38 ` Eric Biggers
2019-08-02 4:38 ` Eric Biggers
2019-08-02 4:38 ` Eric Biggers
2019-08-02 4:38 ` [f2fs-dev] " Eric Biggers
2019-08-12 14:16 ` Theodore Y. Ts'o
2019-08-12 14:16 ` Theodore Y. Ts'o
2019-08-12 14:16 ` [f2fs-dev] " Theodore Y. Ts'o
2019-08-12 14:16 ` Theodore Y. Ts'o
2019-07-26 22:41 ` [PATCH v7 08/16] fscrypt: add FS_IOC_GET_ENCRYPTION_KEY_STATUS ioctl Eric Biggers
2019-07-26 22:41 ` Eric Biggers
2019-07-26 22:41 ` Eric Biggers
2019-07-26 22:41 ` Eric Biggers
2019-07-26 22:41 ` [f2fs-dev] " Eric Biggers
2019-07-28 19:30 ` Theodore Y. Ts'o
2019-07-28 19:30 ` [f2fs-dev] " Theodore Y. Ts'o
2019-07-28 19:30 ` Theodore Y. Ts'o
2019-07-28 19:30 ` Theodore Y. Ts'o
2019-07-26 22:41 ` [PATCH v7 09/16] fscrypt: add an HKDF-SHA512 implementation Eric Biggers
2019-07-26 22:41 ` Eric Biggers
2019-07-26 22:41 ` Eric Biggers
2019-07-26 22:41 ` Eric Biggers
2019-07-26 22:41 ` [f2fs-dev] " Eric Biggers
2019-07-28 19:39 ` Theodore Y. Ts'o
2019-07-28 19:39 ` Theodore Y. Ts'o
2019-07-28 19:39 ` [f2fs-dev] " Theodore Y. Ts'o
2019-07-28 19:39 ` Theodore Y. Ts'o
2019-07-28 19:39 ` Theodore Y. Ts'o
2019-07-29 20:29 ` Eric Biggers
2019-07-29 20:29 ` [f2fs-dev] " Eric Biggers
2019-07-29 20:29 ` Eric Biggers
2019-07-29 20:29 ` Eric Biggers
2019-07-29 21:42 ` James Bottomley
2019-07-29 21:42 ` [f2fs-dev] " James Bottomley
2019-07-29 21:42 ` James Bottomley
2019-07-29 21:42 ` James Bottomley
2019-07-26 22:41 ` [PATCH v7 10/16] fscrypt: v2 encryption policy support Eric Biggers
2019-07-26 22:41 ` Eric Biggers
2019-07-26 22:41 ` Eric Biggers
2019-07-26 22:41 ` Eric Biggers
2019-07-26 22:41 ` [f2fs-dev] " Eric Biggers
2019-07-28 21:17 ` Theodore Y. Ts'o
2019-07-28 21:17 ` [f2fs-dev] " Theodore Y. Ts'o
2019-07-28 21:17 ` Theodore Y. Ts'o
2019-07-28 21:17 ` Theodore Y. Ts'o
2019-07-29 20:46 ` Eric Biggers [this message]
2019-07-29 20:46 ` [f2fs-dev] " Eric Biggers
2019-07-29 20:46 ` Eric Biggers
2019-07-29 20:46 ` Eric Biggers
2019-07-26 22:41 ` [PATCH v7 11/16] fscrypt: allow unprivileged users to add/remove keys for v2 policies Eric Biggers
2019-07-26 22:41 ` Eric Biggers
2019-07-26 22:41 ` Eric Biggers
2019-07-26 22:41 ` Eric Biggers
2019-07-26 22:41 ` [f2fs-dev] " Eric Biggers
2019-07-28 21:22 ` Theodore Y. Ts'o
2019-07-28 21:22 ` [f2fs-dev] " Theodore Y. Ts'o
2019-07-28 21:22 ` Theodore Y. Ts'o
2019-07-28 21:22 ` Theodore Y. Ts'o
2019-07-26 22:41 ` [PATCH v7 12/16] fscrypt: require that key be added when setting a v2 encryption policy Eric Biggers
2019-07-26 22:41 ` Eric Biggers
2019-07-26 22:41 ` Eric Biggers
2019-07-26 22:41 ` Eric Biggers
2019-07-26 22:41 ` [f2fs-dev] " Eric Biggers
2019-07-28 21:24 ` Theodore Y. Ts'o
2019-07-28 21:24 ` [f2fs-dev] " Theodore Y. Ts'o
2019-07-28 21:24 ` Theodore Y. Ts'o
2019-07-28 21:24 ` Theodore Y. Ts'o
2019-07-26 22:41 ` [PATCH v7 13/16] ext4: wire up new fscrypt ioctls Eric Biggers
2019-07-26 22:41 ` Eric Biggers
2019-07-26 22:41 ` Eric Biggers
2019-07-26 22:41 ` Eric Biggers
2019-07-26 22:41 ` [f2fs-dev] " Eric Biggers
2019-07-28 21:24 ` Theodore Y. Ts'o
2019-07-28 21:24 ` [f2fs-dev] " Theodore Y. Ts'o
2019-07-28 21:24 ` Theodore Y. Ts'o
2019-07-28 21:24 ` Theodore Y. Ts'o
2019-07-26 22:41 ` [PATCH v7 14/16] f2fs: " Eric Biggers
2019-07-26 22:41 ` Eric Biggers
2019-07-26 22:41 ` Eric Biggers
2019-07-26 22:41 ` Eric Biggers
2019-07-26 22:41 ` [f2fs-dev] " Eric Biggers
2019-07-30 0:36 ` Jaegeuk Kim
2019-07-30 0:36 ` [f2fs-dev] " Jaegeuk Kim
2019-07-30 0:36 ` Jaegeuk Kim
2019-07-30 0:36 ` Jaegeuk Kim
2019-08-02 8:10 ` Chao Yu
2019-08-02 8:10 ` Chao Yu
2019-08-02 8:10 ` [f2fs-dev] " Chao Yu
2019-08-02 8:10 ` Chao Yu
2019-08-02 8:10 ` Chao Yu
2019-08-02 8:10 ` Chao Yu
2019-08-02 17:31 ` Eric Biggers
2019-08-02 17:31 ` Eric Biggers
2019-08-02 17:31 ` Eric Biggers
2019-08-02 17:31 ` [f2fs-dev] " Eric Biggers
2019-08-04 9:42 ` Chao Yu
2019-08-04 9:42 ` Chao Yu
2019-08-04 9:42 ` Chao Yu
2019-08-04 9:42 ` Chao Yu
2019-08-04 9:42 ` [f2fs-dev] " Chao Yu
2019-07-26 22:41 ` [PATCH v7 15/16] ubifs: " Eric Biggers
2019-07-26 22:41 ` Eric Biggers
2019-07-26 22:41 ` Eric Biggers
2019-07-26 22:41 ` Eric Biggers
2019-07-26 22:41 ` [f2fs-dev] " Eric Biggers
2019-07-30 0:39 ` Theodore Y. Ts'o
2019-07-30 0:39 ` [f2fs-dev] " Theodore Y. Ts'o
2019-07-30 0:39 ` Theodore Y. Ts'o
2019-07-30 0:39 ` Theodore Y. Ts'o
2019-07-26 22:41 ` [PATCH v7 16/16] fscrypt: document the new ioctls and policy version Eric Biggers
2019-07-26 22:41 ` Eric Biggers
2019-07-26 22:41 ` Eric Biggers
2019-07-26 22:41 ` Eric Biggers
2019-07-26 22:41 ` [f2fs-dev] " Eric Biggers
2019-07-29 2:00 ` Theodore Y. Ts'o
2019-07-29 2:00 ` Theodore Y. Ts'o
2019-07-29 2:00 ` [f2fs-dev] " Theodore Y. Ts'o
2019-07-29 2:00 ` Theodore Y. Ts'o
2019-07-29 2:00 ` Theodore Y. Ts'o
2019-07-29 21:36 ` Eric Biggers
2019-07-29 21:36 ` Eric Biggers
2019-07-29 21:36 ` Eric Biggers
2019-07-29 21:36 ` [f2fs-dev] " Eric Biggers
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20190729204627.GH169027@gmail.com \
--to=ebiggers@kernel.org \
--cc=keyrings@vger.kernel.org \
--cc=linux-api@vger.kernel.org \
--cc=linux-crypto@vger.kernel.org \
--cc=linux-ext4@vger.kernel.org \
--cc=linux-f2fs-devel@lists.sourceforge.net \
--cc=linux-fscrypt@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-mtd@lists.infradead.org \
--cc=paulcrowley@google.com \
--cc=satyat@google.com \
--cc=tytso@mit.edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.