From: Henry Jensen <hjensen@gmx.de>
To: ecryptfs@vger.kernel.org
Subject: Re: [PATCH] eCryptfs: Fix directory open regression in linux-stable
Date: Thu, 7 Jul 2016 16:24:31 +0200 [thread overview]
Message-ID: <20160707162431.6c7edb7e@subnote.jensen.local> (raw)
In-Reply-To: <6fe5b584-62b4-c238-916a-3bd68f0a7f20@suse.com>
Hello,
it seems, that none of the suggested patches will be included in
4.4.15? GKH doesn't mention one in his mail "4.4.15-stable review" on
the stable list.
Regards,
Henry
On Tue, 5 Jul 2016 17:14:20 -0400
Jeff Mahoney <jeffm@suse.com> wrote:
> On 6/28/16 11:39 PM, Tyler Hicks wrote:
> > Cherry-picking mainline commit 2f36db71009304b3f0b95afacd8eba1f9f046b87
> > introduces a regression in eCryptfs when mainline commit
> > 6a480a7842545ec520a91730209ec0bae41694c1 (4.6+) is not present. The
> > regression causes all attempts at opening directory files to fail with
> > EMEDIUMTYPE when the lower filesystem's file_operations for directory
> > files do not implement mmap.
> >
> > This is a simple fix that allows the check for the lower file's mmap
> > implementation to be ignored if the lower file is a directory.
>
> I have a different fix that I believe is more correct for this. I would
> have posted it in response to the original fix if it were ever actually
> posted for public discussion.
>
> Denying open is the wrong place to fix this. It's too heavy a hammer
> and, as we see here, a bit fragile.
>
> The right fix is to deny the mmap call instead.
>
> -Jeff
>
> > Signed-off-by: Tyler Hicks <tyhicks@canonical.com>
> > Tested-by: Tyler Hicks <tyhicks@canonical.com> # 4.4.y, 3.18.y
> > Cc: <stable@vger.kernel.org> # 4.5-
> > ---
> > fs/ecryptfs/kthread.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/fs/ecryptfs/kthread.c b/fs/ecryptfs/kthread.c
> > index e818f5a..b9faeab 100644
> > --- a/fs/ecryptfs/kthread.c
> > +++ b/fs/ecryptfs/kthread.c
> > @@ -171,7 +171,7 @@ int ecryptfs_privileged_open(struct file **lower_file,
> > goto out;
> > }
> > have_file:
> > - if ((*lower_file)->f_op->mmap == NULL) {
> > + if ((*lower_file)->f_op->mmap == NULL && !d_is_dir(lower_dentry)) {
> > fput(*lower_file);
> > *lower_file = NULL;
> > rc = -EMEDIUMTYPE;
> >
>
>
> --
> Jeff Mahoney
> SUSE Labs
>
next prev parent reply other threads:[~2016-07-07 14:25 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-06-29 3:39 [PATCH] eCryptfs: Fix directory open regression in linux-stable Tyler Hicks
2016-07-05 21:14 ` Jeff Mahoney
2016-07-07 14:24 ` Henry Jensen [this message]
2016-07-07 18:02 ` Tyler Hicks
2016-07-07 18:19 ` Jeff Mahoney
2016-07-07 23:17 ` Tyler Hicks
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=20160707162431.6c7edb7e@subnote.jensen.local \
--to=hjensen@gmx.de \
--cc=ecryptfs@vger.kernel.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).