On Wed, Aug 17, 2022 at 8:01 PM Al Viro <viro@xxxxxxxxxxxxxxxxxx> wrote: > > On Wed, Aug 17, 2022 at 06:32:15PM -0400, Olga Kornievskaia wrote: > > On Wed, Aug 17, 2022 at 6:18 PM Al Viro <viro@xxxxxxxxxxxxxxxxxx> wrote: > > > > > > My apologies for having missed that back when the SSC > > > patchset had been done (and missing the problems after it got > > > merged, actually). > > > > > > 1) if this > > > r_ino = nfs_fhget(ss_mnt->mnt_sb, src_fh, fattr); > > > in __nfs42_ssc_open() yields a directory inode, we are screwed > > > as soon as it's passed to alloc_file_pseudo() - a *lot* of places > > > in dcache handling would break if we do that. It's not too > > > nice for a regular file from non-cooperating filesystem, but for > > > directory ones it's deadly. > > > > This inode is created to make an appearance of an opened file to do > > (an NFS) read, it's never a directory. > > Er... Where does the fhandle come from? From my reading it's a client-sent > data; I don't know what trust model do you assume, but the price of > getting multiple dentries over the same directory inode is high. > Bogus or compromised client should not be able to cause severe corruption > of kernel data structures... This is an NFS spec specified operation. The (source file's) filehandle comes from the COPY operation compound that the destination server gets and then uses -- creates an inode from using the code you are looking at now -- to access from the source server. Security is all described in the spec. The uniqueness of the filehandle is provided by the source server that created it.
