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

[Greg Kurz]

On Fri, 3 Mar 2017 12:11:36 -0600
Eric Blake <address@hidden> wrote:

> On 03/03/2017 10:43 AM, Greg Kurz 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.
> >>  
> > 
> > O_PATH was supposed to be used as an optimization here, since fds returned 
> > by
> > this function are only passed to openat()... but your comment makes me 
> > realize
> > I inadvertently dropped O_NOFOLLOW between v1 and v2 of the patchset. And 
> > this
> > IS an actual vulnerability issue :) And reading the openat() manpage, I see
> > that O_PATH | O_NOFOLLOW doesn't cause openat() to fail, but to return a fd
> > pointing to the symlink which is certainly not what I want :)  
> 
> Why not? It works, since openat(fd, ...) fails with EBADF if fd is a
> symlink rather than a directory.  (Well, it SHOULD fail like that,
> according to the man page; I need to write a test program and find out
> for sure).  So you don't have to do any additional syscalls, as your
> very next *at call will tell you if you actually got a directory or a
> symlink.
> 

O_PATH | O_NOFOLLOW is a special case as described in the last paragraph
of O_PATH in the man page:

              If  pathname  is a symbolic link and the O_NOFOLLOW flag is also
              specified, then the call returns a file descriptor referring  to
              the  symbolic  link.   This  file  descriptor can be used as the
              dirfd argument in calls to fchownat(2),  fstatat(2),  linkat(2),
              and readlinkat(2) with an empty pathname to have the calls oper‐
              ate on the symbolic link.

Cheers.

--
Greg

pgpAuCiSsZdGW.pgp
Description: OpenPGP digital signature