From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:38828) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XFjbO-0007Rw-2a for qemu-devel@nongnu.org; Fri, 08 Aug 2014 08:49:02 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XFjbK-00011h-2A for qemu-devel@nongnu.org; Fri, 08 Aug 2014 08:48:58 -0400 Received: from mx1.redhat.com ([209.132.183.28]:46256) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XFjbJ-00011K-R7 for qemu-devel@nongnu.org; Fri, 08 Aug 2014 08:48:53 -0400 Message-ID: <53E4C727.6010306@redhat.com> Date: Fri, 08 Aug 2014 06:48:39 -0600 From: Eric Blake MIME-Version: 1.0 References: <1407458425-16110-1-git-send-email-vapier@gentoo.org> In-Reply-To: <1407458425-16110-1-git-send-email-vapier@gentoo.org> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="gMfX9eODbMcjUo70Mkqhn15x7kX3wvXxk" Subject: Re: [Qemu-devel] [PATCH] linux-user: fix readlink handling with magic exe symlink List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Mike Frysinger , qemu-devel@nongnu.org, Riku Voipio Cc: Mike Frysinger This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --gMfX9eODbMcjUo70Mkqhn15x7kX3wvXxk Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 08/07/2014 06:40 PM, Mike Frysinger wrote: > From: Mike Frysinger >=20 > 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. >=20 > 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. >=20 > 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. >=20 > 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 =3D lock_user(VERIFY_WRITE, arg2, arg3, 0); > if (!p || !p2) { > ret =3D -TARGET_EFAULT; > + } else if (!arg3) { > + /* Short circuit this for the magic exe check. */ > + ret =3D -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 =3D realpath(exec_path, real); > - ret =3D temp =3D=3D NULL ? get_errno(-1) : strlen(real= ) ; > - snprintf((char *)p2, arg3, "%s", real); > + /* Return value is # of bytes that we wrote to the buf= fer. */ > + if (temp =3D=3D NULL) { > + ret =3D get_errno(-1); > + } else { > + /* Don't worry about sign mismatch as earlier mapp= ing > + * logic would have thrown a bad address error. */= > + ret =3D 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. --=20 Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org --gMfX9eODbMcjUo70Mkqhn15x7kX3wvXxk Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: Public key at http://people.redhat.com/eblake/eblake.gpg iQEcBAEBCAAGBQJT5McnAAoJEKeha0olJ0NqaYYH/3kazu+FXG6yDyyvHVsGORY7 uFM6YC/eYn4tUSkmydgcRrePBSM//x2MXLcpuigvltsPCvS1J696ZWWx82wtD9GZ zEzqYC/hSA1JYYdiMjvLvJkVuzEhk07+qH7PkkwBszDQccfE5aiPTrVVm+6IO5tt tt8AmhoXOLICnTjNLqreClSRERY6LXJBAfl0X4L8+W0m1zoCvPGP+2v3jsdWgV9z TDvzulKaxMsRQQ7gPioHA7cihuxQUv1D9hK1oHPQdJtDlwGeFr9D+76EBSleOjK8 LYbV/fC0tG8BPfAZ00Ocu3ynk0HC2M559F0yCE7888hhH4abc1snipKoxLaObQ4= =iO8f -----END PGP SIGNATURE----- --gMfX9eODbMcjUo70Mkqhn15x7kX3wvXxk--