linux-kernel - RE: [RFC PATCH 1/2] vfs: pass file down when getattr to avoid losing info.

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <HE1PR0802MB2555AA0A535543B214155BE7F4780@HE1PR0802MB2555.eurprd08.prod.outlook.com>
Date:   Tue, 21 Jul 2020 10:03:23 +0000
From:   Jianyong Wu <Jianyong.Wu@....com>
To:     Dominique Martinet <asmadeus@...ewreck.org>
CC:     "ericvh@...il.com" <ericvh@...il.com>, "hch@....de" <hch@....de>,
        "dhowells@...hat.com" <dhowells@...hat.com>,
        "lucho@...kov.net" <lucho@...kov.net>,
        "v9fs-developer@...ts.sourceforge.net" 
        <v9fs-developer@...ts.sourceforge.net>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        Kaly Xin <Kaly.Xin@....com>, Justin He <Justin.He@....com>,
        Wei Chen <Wei.Chen@....com>
Subject: RE: [RFC PATCH 1/2] vfs: pass file down when getattr to avoid losing
 info.



> -----Original Message-----
> From: Dominique Martinet <asmadeus@...ewreck.org>
> Sent: Monday, July 20, 2020 10:54 PM
> To: Jianyong Wu <Jianyong.Wu@....com>
> Cc: ericvh@...il.com; hch@....de; dhowells@...hat.com;
> lucho@...kov.net; v9fs-developer@...ts.sourceforge.net; linux-
> kernel@...r.kernel.org; Kaly Xin <Kaly.Xin@....com>; Justin He
> <Justin.He@....com>; Wei Chen <Wei.Chen@....com>
> Subject: Re: [RFC PATCH 1/2] vfs: pass file down when getattr to avoid losing
> info.
>
> Jianyong Wu wrote on Mon, Jul 20, 2020:
> > Currently, getting attribute for a file represented by fd is always by
> > inode or path which may lead to bug for a certain network file system.
> > Adding file struct into struct kstat and assigning file for it in
> > vfs_statx_fd can avoid this issue. This change refers to struct istat.
> >
> > Signed-off-by: Jianyong Wu <jianyong.wu@....com>
> > ---
> >  fs/stat.c            | 1 +
> >  include/linux/stat.h | 6 ++++++
> >  2 files changed, 7 insertions(+)
> >
> > diff --git a/fs/stat.c b/fs/stat.c
> > index 44f8ad346db4..0dee5487f6d6 100644
> > --- a/fs/stat.c
> > +++ b/fs/stat.c
> > @@ -147,6 +147,7 @@ int vfs_statx_fd(unsigned int fd, struct kstat *stat,
> >  return -EINVAL;
> >
> >  f = fdget_raw(fd);
> > +stat->filp = f.file;
> >  if (f.file) {
> >  error = vfs_getattr(&f.file->f_path, stat,
> >      request_mask, query_flags);
> > diff --git a/include/linux/stat.h b/include/linux/stat.h index
> > 56614af83d4a..4755c528d49a 100644
> > --- a/include/linux/stat.h
> > +++ b/include/linux/stat.h
> > @@ -48,6 +48,12 @@ struct kstat {
> >  struct timespec64 btime;/* File creation time
> */
> >  u64blocks;
> >  u64mnt_id;
> > +
> > +/*
> > + * Not an attribute, but an auxiliary info for filesystems wanting to
> > + * implement an fstat() like method.
> > + */
> > +struct file*filp;
>
> Just, no ; don't touch this, it isn't likely to get accepted ever.
> file operations should all have a filp around already, we need to fix this in our
> code.
>
Ok, but I think it may not be an easy job to fix it inside 9p.

> (also missing quite a few Cc if you ever want to touch these bits, at least
> linux-fsdevel@)
> thanks. Should have added them.
>
>
> FWIW the problem has been discussed a few times previously.
>
> I'd appreciate if you could take over from Eric and Greg's old series that
> intended to fix that:
> https://lore.kernel.org/lkml/146659832556.15781.17414806975641516683.
> stgit@...ia.lan/
>
> it introduced a race somewhere, but the idea looked good at the time so it's
> worth looking into.

Thanks, I will look into it to find some ideas. if I can get the solution, I will be back.

Thanks
Jianyong
>
> --
> Dominique
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.