From: Eric Biggers
Now that fscrypt_has_permitted_context() compares the fscrypt_context
rather than the fscrypt_info when needed, it is no longer necessary to
delay fscrypt_has_permitted_context() from ->lookup() to ->open() for
regular files, as introduced in commit ff978b09f973 ("ext4 crypto:
From: Eric Biggers
Attempting to link a device node, named pipe, or socket file into an
encrypted directory through rename(2) or link(2) always failed with
EPERM. This happened because fscrypt_permitted_context() saw that the
file was unencrypted and forbid creating the link. This behavior was
From: Eric Biggers
Filesystem encryption is designed to enforce that all files in an
encrypted directory tree use the same encryption policy. Operations
that violate this constraint are supposed to fail with EPERM. There was
one case that was missed, however: the cross-rename operation (i.e.
re
Em Wed, 14 Dec 2016 17:18:57 -0800
Greg Kroah-Hartman escreveu:
> On Wed, Dec 14, 2016 at 04:38:32PM -0800, Linus Torvalds wrote:
> > On Wed, Dec 14, 2016 at 11:18 AM, Jaegeuk Kim wrote:
> > >
> > > BTW, I just downloaded mainline, and tried to build a debian package but
> > > failed due to mi
