On Wed, Aug 17, 2022 at 08:12:27PM -0400, Olga Kornievskaia wrote: > 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. Do we assume that compromise of source server is escalatable at least to kernel panics on the destination server anyway? Confused...
