| Message ID | 20170523003945.14279-4-ebiggers3@gmail.com (mailing list archive) |
|---|---|
| State | Not Applicable |
| Headers | show |
On Tue, May 23, 2017 at 2:39 AM, Eric Biggers <ebiggers3@gmail.com> wrote: > From: Eric Biggers <ebiggers@google.com> > > Since only an open file can be mmap'ed, and we only allow open()ing an > encrypted file when its key is available, there is no need to check for > the key again before permitting each mmap(). > > Signed-off-by: Eric Biggers <ebiggers@google.com> Acked-by: Richard Weinberger <richard@nod.at>
On Tue, May 23, 2017 at 04:14:20PM +0200, Richard Weinberger wrote: > On Tue, May 23, 2017 at 2:39 AM, Eric Biggers <ebiggers3@gmail.com> wrote: > > From: Eric Biggers <ebiggers@google.com> > > > > Since only an open file can be mmap'ed, and we only allow open()ing an > > encrypted file when its key is available, there is no need to check for > > the key again before permitting each mmap(). > > > > Signed-off-by: Eric Biggers <ebiggers@google.com> > > Acked-by: Richard Weinberger <richard@nod.at> There are some patches that were sent to linux-fscrypt (including this one) that are specific to ubifs that don't appear to be in linux-next as of this writing. I can include them in the fscrypt tree (which I am updating somewhat belatedly; sorry, crazy travel schedule has made me be late attending to fscrypt), but it probably makes more sense for the change to go in via the ubifs tree. The f2fs version of the "don't bother checking for encryption key" is already in linux-next, via the f2fs tree, for example. So I'm planning on NOT taking the ubifs-specific patches that are in the linux-fscrypto patch queue; unless Richard, you want to specifically ask me to do so. Cheers, - Ted -- To unsubscribe from this list: send the line "unsubscribe linux-fscrypt" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Ted + Richard, On Fri, Jun 23, 2017 at 12:09:07PM -0400, Theodore Ts'o wrote: > On Tue, May 23, 2017 at 04:14:20PM +0200, Richard Weinberger wrote: > > On Tue, May 23, 2017 at 2:39 AM, Eric Biggers <ebiggers3@gmail.com> wrote: > > > From: Eric Biggers <ebiggers@google.com> > > > > > > Since only an open file can be mmap'ed, and we only allow open()ing an > > > encrypted file when its key is available, there is no need to check for > > > the key again before permitting each mmap(). > > > > > > Signed-off-by: Eric Biggers <ebiggers@google.com> > > > > Acked-by: Richard Weinberger <richard@nod.at> > > There are some patches that were sent to linux-fscrypt (including this > one) that are specific to ubifs that don't appear to be in linux-next > as of this writing. > > I can include them in the fscrypt tree (which I am updating somewhat > belatedly; sorry, crazy travel schedule has made me be late attending > to fscrypt), but it probably makes more sense for the change to go in > via the ubifs tree. The f2fs version of the "don't bother checking > for encryption key" is already in linux-next, via the f2fs tree, for > example. > > So I'm planning on NOT taking the ubifs-specific patches that are in > the linux-fscrypto patch queue; unless Richard, you want to > specifically ask me to do so. > The mmap and truncate patches were basically the same for each filesystem, but yes it's fine for them to go in separately. Richard, can you take for ubifs: ubifs: don't bother checking for encryption key in ->mmap() ubifs: require key for truncate(2) of encrypted file and Ted can you take for ext4: ext4: don't bother checking for encryption key in ->mmap() ext4: require key for truncate(2) of encrypted file - Eric -- To unsubscribe from this list: send the line "unsubscribe linux-fscrypt" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Ted, Eric, Am 23.06.2017 um 19:18 schrieb Eric Biggers: > Ted + Richard, > > On Fri, Jun 23, 2017 at 12:09:07PM -0400, Theodore Ts'o wrote: >> On Tue, May 23, 2017 at 04:14:20PM +0200, Richard Weinberger wrote: >>> On Tue, May 23, 2017 at 2:39 AM, Eric Biggers <ebiggers3@gmail.com> wrote: >>>> From: Eric Biggers <ebiggers@google.com> >>>> >>>> Since only an open file can be mmap'ed, and we only allow open()ing an >>>> encrypted file when its key is available, there is no need to check for >>>> the key again before permitting each mmap(). >>>> >>>> Signed-off-by: Eric Biggers <ebiggers@google.com> >>> >>> Acked-by: Richard Weinberger <richard@nod.at> >> >> There are some patches that were sent to linux-fscrypt (including this >> one) that are specific to ubifs that don't appear to be in linux-next >> as of this writing. >> >> I can include them in the fscrypt tree (which I am updating somewhat >> belatedly; sorry, crazy travel schedule has made me be late attending >> to fscrypt), but it probably makes more sense for the change to go in >> via the ubifs tree. The f2fs version of the "don't bother checking >> for encryption key" is already in linux-next, via the f2fs tree, for >> example. >> >> So I'm planning on NOT taking the ubifs-specific patches that are in >> the linux-fscrypto patch queue; unless Richard, you want to >> specifically ask me to do so. >> > > The mmap and truncate patches were basically the same for each filesystem, but > yes it's fine for them to go in separately. Richard, can you take for ubifs: > > ubifs: don't bother checking for encryption key in ->mmap() > ubifs: require key for truncate(2) of encrypted file Alright, I'll carry them. :-) The plan is that the fscrypt tree will just contain fscrypt "core" patches and global changes/cleanups go thought the individual filesystem trees, right? Thanks, //richard -- To unsubscribe from this list: send the line "unsubscribe linux-fscrypt" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Fri, Jun 23, 2017 at 07:20:51PM +0200, Richard Weinberger wrote: > > The plan is that the fscrypt tree will just contain fscrypt "core" patches and > global changes/cleanups go thought the individual filesystem trees, right? Yes, it minimizes potential conflicts against other individual file system trees if we keep patches that are file system specific in their own tree. There will be times when we can't do that --- for example, if we need to make a change in the fscrypt directory that requires matching changes in all of the users of fscrypt at the same time. But when we do that there is always the chance that there will be merge conflicts that have to be manually reconciled by both Stephen Rothwell for linux-next and Linus during the merge window. But if we can avoid needing to do that, it's generally easier for all concerned. Cheers, - Ted -- To unsubscribe from this list: send the line "unsubscribe linux-fscrypt" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/fs/ubifs/file.c b/fs/ubifs/file.c index 2cda3d67e2d0..7dc58bda279b 100644 --- a/fs/ubifs/file.c +++ b/fs/ubifs/file.c @@ -1607,15 +1607,6 @@ static const struct vm_operations_struct ubifs_file_vm_ops = { static int ubifs_file_mmap(struct file *file, struct vm_area_struct *vma) { int err; - struct inode *inode = file->f_mapping->host; - - if (ubifs_crypt_is_encrypted(inode)) { - err = fscrypt_get_encryption_info(inode); - if (err) - return -EACCES; - if (!fscrypt_has_encryption_key(inode)) - return -ENOKEY; - } err = generic_file_mmap(file, vma); if (err)