On Fri, Mar 03, 2017 at 10:40:13AM -0600, Eric Blake wrote: > On 03/03/2017 10:21 AM, Daniel P. Berrange wrote: > > >> > >> +#ifndef O_PATH > >> + #define O_PATH 0 > >> +#endif > > > > Isn't the use of O_PATH required in order to fix the recent > > security vulnerability in 9p ? If so, then defining it to > > 0 means the QEMU is silently becoming vulnerable once again > > which I don't think is a good idea. > > My understanding is that O_PATH is an optimization. It lets openat() > succeed in some places where it would ordinarily fail (for example, it > can be used to open a dir with mode 0000) - the resulting fd is > limited-use (it cannot be used to read() or write(), but CAN be used as > the relative fd for a subsequent openat(), for example). If you define > O_PATH to 0, then attempts to traverse paths will fail where the could > have otherwise succeeded, but failure is okay (the CVE was that we were > succeeding at opening through a guest-controlled symlink; whether we now > fail or guarantee that we are not going through a symlink is a quality > of implementation, but either way, we are at least immune from > succeeding through a symlink).
So we're not vulnerable, but we are breaking some valid guest usage. I don't much like the idea of doing that silently, but i guess there's no better alternative. Regards, Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://entangle-photo.org -o- http://search.cpan.org/~danberr/ :|
