On Thu, Sep 27, 2018 at 9:36 AM Miklos Szeredi <miklos@xxxxxxxxxx> wrote: > > On Thu, Sep 27, 2018 at 8:05 AM, Amir Goldstein <amir73il@xxxxxxxxx> wrote: > > > So this is interesting... if there is a file in overlayfs lower layer with > > the f_op read = seq_read then &p->lock in the chain above could be > > takes after ovl locks and that is in reveres order to the order of locks > > in execve on an overlayfs file. > > > > On the one hand, it is possible (not sure if desirable) to use filesystems > > with seq_file like debugfs as overlay lower fs, but on the other hand, > > it is not possible to copy up a debugfs file with its original content > > because (at least for most files I looked) the inode size is reported as 0. > > > > Also, from v4.19-rc1, with stacked f_op, ovl_read_iter() calls vfs_iter_read(), > > so overlayfs is no longer tolerant to underlying files that implement f_op read > > (and not read_iter), thus, it is no longer possible to read lower debugfs files. > > > > That said, if there are files in lower layer that user seq_read f_op and have > > non zero inode size, the deadlock reported above might be possible. > > > > Miklos, > > > > What do you recon we should do? > > Blacklist debugfs just like procfs was blacklisted from fs stacking? > > Improve the heuristics of ovl_dentry_weird() to cover debugfs and friends? > > I think that's the best plan. There doesn't seem to be any sense in > supporting debugfs and similar weirdness as lower layer, so the best > course of action would be to deny at the earilest possible point in > time. > OK. I will leave to you to find the Weirdest Common Denominator of debugfs and friends. But there could also be a filesystem with sporadic special files with seq_read (or no read_iter f_op), or maybe our Weird heuristics didn't catch the filesystem. We might want to block those files from being copied up on the grounds that they cannot be read from overlay before copy up anyway. Thanks, Amir.
