qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] git master build failure in 9pfs


From: Daniel P. Berrange
Subject: Re: [Qemu-devel] git master build failure in 9pfs
Date: Fri, 3 Mar 2017 16:42:33 +0000
User-agent: Mutt/1.7.1 (2016-10-04)

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/ :|



reply via email to

[Prev in Thread] Current Thread [Next in Thread]