From: Greg Kurz <groug@kaod.org>
To: Eric Blake <eblake@redhat.com>
Cc: "Daniel P. Berrange" <berrange@redhat.com>,
G 3 <programmingkidx@gmail.com>,
Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>,
qemu-devel qemu-devel <qemu-devel@nongnu.org>
Subject: Re: [Qemu-devel] git master build failure in 9pfs
Date: Fri, 3 Mar 2017 19:15:24 +0100 [thread overview]
Message-ID: <20170303191524.048b2d1f@bahia.lan> (raw)
In-Reply-To: <a93b0903-cf60-d21b-2d68-cd182e06aed3@redhat.com>
[-- Attachment #1: Type: text/plain, Size: 1889 bytes --]
On Fri, 3 Mar 2017 12:11:36 -0600
Eric Blake <eblake@redhat.com> 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
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]
next prev parent reply other threads:[~2017-03-03 18:15 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <mailman.56273.1488553194.22740.qemu-devel@nongnu.org>
2017-03-03 15:28 ` [Qemu-devel] git master build failure in 9pfs G 3
2017-03-03 15:44 ` Greg Kurz
2017-03-03 15:55 ` G 3
2017-03-03 15:58 ` Peter Maydell
2017-03-03 16:02 ` G 3
2017-03-03 16:14 ` Greg Kurz
2017-03-03 16:21 ` Daniel P. Berrange
2017-03-03 16:38 ` G 3
2017-03-03 16:40 ` Eric Blake
2017-03-03 16:42 ` Daniel P. Berrange
2017-03-03 16:45 ` Eric Blake
2017-03-03 16:43 ` Greg Kurz
2017-03-03 18:11 ` Eric Blake
2017-03-03 18:15 ` Greg Kurz [this message]
2017-03-03 18:28 ` Eric Blake
2017-03-04 10:57 ` Greg Kurz
[not found] <mailman.56353.1488479169.22739.qemu-devel@nongnu.org>
2017-03-03 0:30 ` Programmingkid
2017-03-02 17:28 Mark Cave-Ayland
2017-03-02 17:40 ` Daniel P. Berrange
2017-03-02 18:10 ` Peter Maydell
2017-03-03 15:41 ` Greg Kurz
2017-03-03 14:43 ` Mark Cave-Ayland
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20170303191524.048b2d1f@bahia.lan \
--to=groug@kaod.org \
--cc=berrange@redhat.com \
--cc=eblake@redhat.com \
--cc=mark.cave-ayland@ilande.co.uk \
--cc=programmingkidx@gmail.com \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.