On 8/24/21 6:15 PM, Greg Kurz wrote: > On Fri, 20 Aug 2021 13:03:23 +0800 > JeffleXu <jefflexu@xxxxxxxxxxxxxxxxx> wrote: >> >> Fine. Got it. However the returned fd (opened without O_PATH) is only >> used for FS_IOC_GETFLAGS/FS_IOC_FSGETXATTR ioctl, while in most cases >> for special device files, these two ioctls should return -ENOTTY. >> > > The actual problem is that a FIFO will cause openat() to block until > the other end of the FIFO is open for writing... Got it. > >> If it's really a security issue, then lo_inode_open() could be used to > > ... and cause a DoS on virtiofsd. So yes, this is a security issue and > lo_inode_open() was introduced specifically to handle this. > >> get a temporary fd, i.e., check if it's a special file before opening. >> After all, FUSE_OPEN also handles in this way. Besides, I can't >> understand what "race-free way" means. >> > > "race-free way" means a way that guarantees that file type > cannot change between the time you check it and the time > you open it (TOCTOU error). For example, doing a plain stat(), > checking st_mode and proceeding to open() is wrong : nothing > prevents the file to be unlinked and replaced by something > else between stat() and open(). > > We avoid that by keeping O_PATH fds around and using > lo_inode_open() instead of openat(). Thanks for the detailed explanation. Got it. > > In your case, it seems that you should do the checking after > you have an actual lo_inode for the target file, and pass > that to lo_should_enable_dax() instead of the parent lo_inode > and target name. > Yes, that will be more reasonable. Thanks. -- Thanks, Jeffle _______________________________________________ Virtualization mailing list Virtualization@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linuxfoundation.org/mailman/listinfo/virtualization
