Re: [ksmbd] racy uses of ->d_parent and ->d_name

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

 



On Thu, Feb 03, 2022 at 04:02:45AM +0000, Al Viro wrote:
On Thu, Feb 03, 2022 at 08:16:21AM +0900, Namjae Jeon wrote:

> 	Why is so much tied to "open, then figure out where it is" model?
> Is it a legacy of userland implementation, or a network fs protocol that
> manages to outsuck NFS, or...?
It need to use absolute based path given from request.

Er... yes?  Normal syscalls also have to be able to deal with pathnames;
the sane way for e.g. unlink() is to traverse everything except the last
component, then do inode_lock() on the directory you've arrived at, do
lookup for the final component and do the operation.

What we do not attempt is "walk the entire path, then try to lock the
parent of whatever we'd arrived at, then do operation".  Otherwise
we'd have the same kind of headache in all directory-manipulating
syscalls...

What's the problem with doing the same thing here?  Lack of convenient
exported helpers for some of those?  Then let's sort _that_ out...
If there's something else, I'd like to know what exactly it is.

Samba recently did a complete VFS rewrite to remove almost
*all* pathname-based calls for exactly this reason (remove
all possibility of symlink races).

https://www.samba.org/samba/security/CVE-2021-20316.html

Is this essentially the same bug affecting ksmbd here ?

If so, the pathname processing will need to be re-worked
in the same way we had to do for Samba.



[Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux