Re: [RFC] problems with alloc_file_pseudo() use in __nfs42_ssc_open()

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.



[Index of Archives]     [Linux Ext4 Filesystem]     [Union Filesystem]     [Filesystem Testing]     [Ceph Users]     [Ecryptfs]     [NTFS 3]     [AutoFS]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux Cachefs]     [Reiser Filesystem]     [Linux RAID]     [NTFS 3]     [Samba]     [Device Mapper]     [CEPH Development]

  Powered by Linux