qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Eric Blake <eblake@redhat.com>
To: Mike Frysinger <vapier@gentoo.org>,
	qemu-devel@nongnu.org, Riku Voipio <riku.voipio@iki.fi>
Cc: Mike Frysinger <vapier@chromium.org>
Subject: Re: [Qemu-devel] [PATCH] linux-user: fix readlink handling with magic exe symlink
Date: Fri, 08 Aug 2014 06:48:39 -0600	[thread overview]
Message-ID: <53E4C727.6010306@redhat.com> (raw)
In-Reply-To: <1407458425-16110-1-git-send-email-vapier@gentoo.org>

[-- Attachment #1: Type: text/plain, Size: 3107 bytes --]

On 08/07/2014 06:40 PM, Mike Frysinger wrote:
> From: Mike Frysinger <vapier@chromium.org>
> 
> The current code always returns the length of the path when it should
> be returning the number of bytes it wrote to the output string.

That is indeed a bug.

> 
> Further, readlink is not supposed to append a NUL byte, but the current
> snprintf logic will always do just that.

Not true.  readlink() is not required to append NUL, but is permitted to
append NUL as long as the return value is less than the input size.
However, you are correct that if the input bufsize matches the return
value, or if the intput buffer is too small, then the output must be
truncated without the use of a NUL byte.

> 
> Even further, if you pass in a length of 0, you're suppoesd to get back
> an error (EINVAL), but the current logic just returns 0.

Not true.  POSIX does not require that.  This is just a special case of
the buf argument not being large enough to contain the content, in which
case it is acceptable to return a positive value of the number of bytes
written (0) - and the user should have the clue that since the input
size matches the output size that the input size was possibly too small.
http://pubs.opengroup.org/onlinepubs/9699919799/functions/readlink.html

The fact that Linux returns EINVAL in this case is arguably a bug in
Linux being non-compliant to POSIX, or conversely a bug in POSIX for not
allowing this behavior.


> 
> diff --git a/linux-user/syscall.c b/linux-user/syscall.c
> index a50229d..bd10a6b 100644
> --- a/linux-user/syscall.c
> +++ b/linux-user/syscall.c
> @@ -6620,11 +6620,22 @@ abi_long do_syscall(void *cpu_env, int num, abi_long arg1,
>              p2 = lock_user(VERIFY_WRITE, arg2, arg3, 0);
>              if (!p || !p2) {
>                  ret = -TARGET_EFAULT;
> +            } else if (!arg3) {
> +                /* Short circuit this for the magic exe check. */
> +                ret = -TARGET_EINVAL;

Thus, I think this hunk is nice for Linux compatibility, but not
necessary per POSIX.

>              } else if (is_proc_myself((const char *)p, "exe")) {
>                  char real[PATH_MAX], *temp;
>                  temp = realpath(exec_path, real);
> -                ret = temp == NULL ? get_errno(-1) : strlen(real) ;
> -                snprintf((char *)p2, arg3, "%s", real);
> +                /* Return value is # of bytes that we wrote to the buffer. */
> +                if (temp == NULL) {
> +                    ret = get_errno(-1);
> +                } else {
> +                    /* Don't worry about sign mismatch as earlier mapping
> +                     * logic would have thrown a bad address error. */
> +                    ret = MIN(strlen(real), arg3);
> +                    /* We cannot NUL terminate the string. */
> +                    memcpy(p2, real, ret);

Same for this comment - nice for Linux compatibility, but not necessary
per POSIX.

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 539 bytes --]

  reply	other threads:[~2014-08-08 12:49 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-08-08  0:40 [Qemu-devel] [PATCH] linux-user: fix readlink handling with magic exe symlink Mike Frysinger
2014-08-08 12:48 ` Eric Blake [this message]
2014-08-08 13:48   ` Mike Frysinger

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=53E4C727.6010306@redhat.com \
    --to=eblake@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=riku.voipio@iki.fi \
    --cc=vapier@chromium.org \
    --cc=vapier@gentoo.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).