[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAJfpegvpEkB2HL5THcUsmBVvcru1-DkSTo_DmA4pWNU_TV7ODg@mail.gmail.com>
Date: Fri, 11 Dec 2020 15:44:21 +0100
From: Miklos Szeredi <miklos@...redi.hu>
To: Amir Goldstein <amir73il@...il.com>
Cc: Miklos Szeredi <mszeredi@...hat.com>,
"Eric W . Biederman" <ebiederm@...ssion.com>,
linux-fsdevel <linux-fsdevel@...r.kernel.org>,
overlayfs <linux-unionfs@...r.kernel.org>,
LSM List <linux-security-module@...r.kernel.org>,
linux-kernel <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v2 08/10] ovl: do not fail because of O_NOATIME
On Tue, Dec 8, 2020 at 12:32 PM Amir Goldstein <amir73il@...il.com> wrote:
>
> On Mon, Dec 7, 2020 at 6:37 PM Miklos Szeredi <mszeredi@...hat.com> wrote:
> >
> > In case the file cannot be opened with O_NOATIME because of lack of
> > capabilities, then clear O_NOATIME instead of failing.
> >
> > Signed-off-by: Miklos Szeredi <mszeredi@...hat.com>
> > ---
> > fs/overlayfs/file.c | 5 +++--
> > 1 file changed, 3 insertions(+), 2 deletions(-)
> >
> > diff --git a/fs/overlayfs/file.c b/fs/overlayfs/file.c
> > index dc767034d37b..d6ac7ac66410 100644
> > --- a/fs/overlayfs/file.c
> > +++ b/fs/overlayfs/file.c
> > @@ -53,9 +53,10 @@ static struct file *ovl_open_realfile(const struct file *file,
> > err = inode_permission(realinode, MAY_OPEN | acc_mode);
> > if (err) {
> > realfile = ERR_PTR(err);
> > - } else if (!inode_owner_or_capable(realinode)) {
> > - realfile = ERR_PTR(-EPERM);
> > } else {
> > + if (!inode_owner_or_capable(realinode))
> > + flags &= ~O_NOATIME;
> > +
>
> Isn't that going to break:
>
> flags |= OVL_OPEN_FLAGS;
>
> /* If some flag changed that cannot be changed then something's amiss */
> if (WARN_ON((file->f_flags ^ flags) & ~OVL_SETFL_MASK))
>
> IOW setting a flag that is allowed to change will fail because of
> missing O_ATIME in file->f_flags.
Well spotted. I just removed those lines as a fix. The check never
triggered since its introduction in 4.19, so I guess it isn't worth
adding more complexity for.
>
> I guess we need test coverage for SETFL.
There might be some in ltp, haven't checked. Would be nice if the fs
related ltp tests could be integrated into xfstests.
Thanks,
Miklos
Powered by blists - more mailing lists