From: "Theodore Y. Ts'o" <tytso@mit.edu>
To: Eric Biggers <ebiggers@kernel.org>
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 08/16] fscrypt: add FS_IOC_GET_ENCRYPTION_KEY_STATUS ioctl
Date: Sun, 28 Jul 2019 15:30:12 -0400 [thread overview]
Message-ID: <20190728193012.GH6088@mit.edu> (raw)
In-Reply-To: <20190726224141.14044-9-ebiggers@kernel.org>
On Fri, Jul 26, 2019 at 03:41:33PM -0700, Eric Biggers wrote:
> From: Eric Biggers <ebiggers@google.com>
>
> Add a new fscrypt ioctl, FS_IOC_GET_ENCRYPTION_KEY_STATUS. Given a key
> specified by 'struct fscrypt_key_specifier' (the same way a key is
> specified for the other fscrypt key management ioctls), it returns
> status information in a 'struct fscrypt_get_key_status_arg'.
>
> The main motivation for this is that applications need to be able to
> check whether an encrypted directory is "unlocked" or not, so that they
> can add the key if it is not, and avoid adding the key (which may
> involve prompting the user for a passphrase) if it already is.
>
> It's possible to use some workarounds such as checking whether opening a
> regular file fails with ENOKEY, or checking whether the filenames "look
> like gibberish" or not. However, no workaround is usable in all cases.
>
> Like the other key management ioctls, the keyrings syscalls may seem at
> first to be a good fit for this. Unfortunately, they are not. Even if
> we exposed the keyring ID of the ->s_master_keys keyring and gave
> everyone Search permission on it (note: currently the keyrings
> permission system would also allow everyone to "invalidate" the keyring
> too), the fscrypt keys have an additional state that doesn't map cleanly
> to the keyrings API: the secret can be removed, but we can be still
> tracking the files that were using the key, and the removal can be
> re-attempted or the secret added again.
>
> After later patches, some applications will also need a way to determine
> whether a key was added by the current user vs. by some other user.
> Reserved fields are included in fscrypt_get_key_status_arg for this and
> other future extensions.
>
> Signed-off-by: Eric Biggers <ebiggers@google.com>
Looks good, feel free to add:
Reviewed-by: Theodore Ts'o <tytso@mit.edu>
WARNING: multiple messages have this Message-ID (diff)
From: "Theodore Y. Ts'o" <tytso@mit.edu>
To: Eric Biggers <ebiggers@kernel.org>
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 08/16] fscrypt: add FS_IOC_GET_ENCRYPTION_KEY_STATUS ioctl
Date: Sun, 28 Jul 2019 19:30:12 +0000 [thread overview]
Message-ID: <20190728193012.GH6088@mit.edu> (raw)
In-Reply-To: <20190726224141.14044-9-ebiggers@kernel.org>
On Fri, Jul 26, 2019 at 03:41:33PM -0700, Eric Biggers wrote:
> From: Eric Biggers <ebiggers@google.com>
>
> Add a new fscrypt ioctl, FS_IOC_GET_ENCRYPTION_KEY_STATUS. Given a key
> specified by 'struct fscrypt_key_specifier' (the same way a key is
> specified for the other fscrypt key management ioctls), it returns
> status information in a 'struct fscrypt_get_key_status_arg'.
>
> The main motivation for this is that applications need to be able to
> check whether an encrypted directory is "unlocked" or not, so that they
> can add the key if it is not, and avoid adding the key (which may
> involve prompting the user for a passphrase) if it already is.
>
> It's possible to use some workarounds such as checking whether opening a
> regular file fails with ENOKEY, or checking whether the filenames "look
> like gibberish" or not. However, no workaround is usable in all cases.
>
> Like the other key management ioctls, the keyrings syscalls may seem at
> first to be a good fit for this. Unfortunately, they are not. Even if
> we exposed the keyring ID of the ->s_master_keys keyring and gave
> everyone Search permission on it (note: currently the keyrings
> permission system would also allow everyone to "invalidate" the keyring
> too), the fscrypt keys have an additional state that doesn't map cleanly
> to the keyrings API: the secret can be removed, but we can be still
> tracking the files that were using the key, and the removal can be
> re-attempted or the secret added again.
>
> After later patches, some applications will also need a way to determine
> whether a key was added by the current user vs. by some other user.
> Reserved fields are included in fscrypt_get_key_status_arg for this and
> other future extensions.
>
> Signed-off-by: Eric Biggers <ebiggers@google.com>
Looks good, feel free to add:
Reviewed-by: Theodore Ts'o <tytso@mit.edu>
WARNING: multiple messages have this Message-ID (diff)
From: "Theodore Y. Ts'o" <tytso@mit.edu>
To: Eric Biggers <ebiggers@kernel.org>
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 08/16] fscrypt: add FS_IOC_GET_ENCRYPTION_KEY_STATUS ioctl
Date: Sun, 28 Jul 2019 15:30:12 -0400 [thread overview]
Message-ID: <20190728193012.GH6088@mit.edu> (raw)
In-Reply-To: <20190726224141.14044-9-ebiggers@kernel.org>
On Fri, Jul 26, 2019 at 03:41:33PM -0700, Eric Biggers wrote:
> From: Eric Biggers <ebiggers@google.com>
>
> Add a new fscrypt ioctl, FS_IOC_GET_ENCRYPTION_KEY_STATUS. Given a key
> specified by 'struct fscrypt_key_specifier' (the same way a key is
> specified for the other fscrypt key management ioctls), it returns
> status information in a 'struct fscrypt_get_key_status_arg'.
>
> The main motivation for this is that applications need to be able to
> check whether an encrypted directory is "unlocked" or not, so that they
> can add the key if it is not, and avoid adding the key (which may
> involve prompting the user for a passphrase) if it already is.
>
> It's possible to use some workarounds such as checking whether opening a
> regular file fails with ENOKEY, or checking whether the filenames "look
> like gibberish" or not. However, no workaround is usable in all cases.
>
> Like the other key management ioctls, the keyrings syscalls may seem at
> first to be a good fit for this. Unfortunately, they are not. Even if
> we exposed the keyring ID of the ->s_master_keys keyring and gave
> everyone Search permission on it (note: currently the keyrings
> permission system would also allow everyone to "invalidate" the keyring
> too), the fscrypt keys have an additional state that doesn't map cleanly
> to the keyrings API: the secret can be removed, but we can be still
> tracking the files that were using the key, and the removal can be
> re-attempted or the secret added again.
>
> After later patches, some applications will also need a way to determine
> whether a key was added by the current user vs. by some other user.
> Reserved fields are included in fscrypt_get_key_status_arg for this and
> other future extensions.
>
> Signed-off-by: Eric Biggers <ebiggers@google.com>
Looks good, feel free to add:
Reviewed-by: Theodore Ts'o <tytso@mit.edu>
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
WARNING: multiple messages have this Message-ID (diff)
From: "Theodore Y. Ts'o" <tytso@mit.edu>
To: Eric Biggers <ebiggers@kernel.org>
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 08/16] fscrypt: add FS_IOC_GET_ENCRYPTION_KEY_STATUS ioctl
Date: Sun, 28 Jul 2019 15:30:12 -0400 [thread overview]
Message-ID: <20190728193012.GH6088@mit.edu> (raw)
In-Reply-To: <20190726224141.14044-9-ebiggers@kernel.org>
On Fri, Jul 26, 2019 at 03:41:33PM -0700, Eric Biggers wrote:
> From: Eric Biggers <ebiggers@google.com>
>
> Add a new fscrypt ioctl, FS_IOC_GET_ENCRYPTION_KEY_STATUS. Given a key
> specified by 'struct fscrypt_key_specifier' (the same way a key is
> specified for the other fscrypt key management ioctls), it returns
> status information in a 'struct fscrypt_get_key_status_arg'.
>
> The main motivation for this is that applications need to be able to
> check whether an encrypted directory is "unlocked" or not, so that they
> can add the key if it is not, and avoid adding the key (which may
> involve prompting the user for a passphrase) if it already is.
>
> It's possible to use some workarounds such as checking whether opening a
> regular file fails with ENOKEY, or checking whether the filenames "look
> like gibberish" or not. However, no workaround is usable in all cases.
>
> Like the other key management ioctls, the keyrings syscalls may seem at
> first to be a good fit for this. Unfortunately, they are not. Even if
> we exposed the keyring ID of the ->s_master_keys keyring and gave
> everyone Search permission on it (note: currently the keyrings
> permission system would also allow everyone to "invalidate" the keyring
> too), the fscrypt keys have an additional state that doesn't map cleanly
> to the keyrings API: the secret can be removed, but we can be still
> tracking the files that were using the key, and the removal can be
> re-attempted or the secret added again.
>
> After later patches, some applications will also need a way to determine
> whether a key was added by the current user vs. by some other user.
> Reserved fields are included in fscrypt_get_key_status_arg for this and
> other future extensions.
>
> Signed-off-by: Eric Biggers <ebiggers@google.com>
Looks good, feel free to add:
Reviewed-by: Theodore Ts'o <tytso@mit.edu>
_______________________________________________
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-28 19:30 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 [this message]
2019-07-28 19:30 ` 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
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=20190728193012.GH6088@mit.edu \
--to=tytso@mit.edu \
--cc=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 \
/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.