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
