Re: [PATCH 00/18] new API for FS_IOC_[GS]ETFLAGS/FS_IOC_FS[GS]ETXATTR

[Miklos Szeredi]

On Wed, Feb 3, 2021 at 3:28 PM Matthew Wilcox <willy@xxxxxxxxxxxxx> wrote:
>
> On Wed, Feb 03, 2021 at 03:13:29PM +0100, Miklos Szeredi wrote:
> > On Wed, Feb 3, 2021 at 2:58 PM Matthew Wilcox <willy@xxxxxxxxxxxxx> wrote:
> >
> > > Network filesystems frequently need to use the credentials attached to
> > > a struct file in order to communicate with the server.  There's no point
> > > fighting this reality.
> >
> > IDGI.  Credentials can be taken from the file and from the task.  In
> > this case every filesystem except cifs looks at task creds. Why are
> > network filesystem special in this respect?
>
> I don't necessarily mean 'struct cred'.  I mean "the authentication
> that the client has performed to the server".  Which is not a per-task
> thing, it's stored in the struct file, which is why we have things like
>
>         int (*write_begin)(struct file *, struct address_space *mapping,
>                                 loff_t pos, unsigned len, unsigned flags,
>                                 struct page **pagep, void **fsdata);
>
> disk filesystems ignore the struct file argument, but network filesystems
> very much use it.

Fine for file I/O.  That's authorized at open time for all
filesystems, not just network ones.

Not fine for metadata operations (IMO).   I.e. ->[gs]etattr() don't
take a file argument either, even though on the uAPI there are plenty
of open file based variants.

Thanks,
Miklos