All of lore.kernel.org
 help / color / mirror / Atom feed
From: Corey Bryant <coreyb@linux.vnet.ibm.com>
To: Eric Blake <eblake@redhat.com>
Cc: kwolf@redhat.com, aliguori@us.ibm.com, qemu-devel@nongnu.org,
	stefanha@linux.vnet.ibm.com
Subject: Re: [Qemu-devel] [PATCH 2/3] block: Add support to "open" /dev/fd/X filenames
Date: Mon, 04 Jun 2012 12:28:36 -0400	[thread overview]
Message-ID: <4FCCE234.5040109@linux.vnet.ibm.com> (raw)
In-Reply-To: <4FCCDC55.5070705@redhat.com>



On 06/04/2012 12:03 PM, Eric Blake wrote:
> On 06/04/2012 09:51 AM, Corey Bryant wrote:
>
>>>> +
>>>> +    if (strstart(filename, "/dev/fd/",&p)) {
>>>> +        fd = atoi(p);
>>>
>>> atoi() is lousy - it has no error checking, and returns 0 if a mistake
>>> was made.  You really want to be using strtol (or even better, a
>>> sensible wrapper around strtol that takes care of the subtleties of
>>> calling it correctly), so that you don't end up dup'ing stdin when the
>>> user passes a bad /dev/fd/ string.
>>>
>>
>> It looks like strtol returns 0 on failure too.  Do we need to support
>> stdin/stdout/stderr?
>
> But at least strtol lets you detect errors:
>
> char *tmp;
> errno = 0;
> fd = strtol(p,&tmp, 10);
> if (errno || tmp == p) {
>      /* raise your error here */
> }

I don't think this is legitimate.  errno can be set under the covers of 
library calls even if the strtol() call is successful.

I was thinking if strtol returns 0 and errno is 0, perhaps we could 
assume success, but I don't think this is guaranteed either.

Maybe a combination of isdigit() then strtol() will give a better idea 
of success.

>
> and if you get past that point, then someone really did pass in
> /dev/fd/0 as the string they meant to be parsed (probably a user bug, as
> getfd is unlikely to ever return 0 unless you start with stdin closed,
> which itself is something that POSIX discourages, but not something we
> need to specifically worry about).  So I would argue that yes, we do
> need to support fd 0, if only by not special casing it as compared to
> any other valid fd.
>

Ok

-- 
Regards,
Corey

  reply	other threads:[~2012-06-04 16:29 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-06-04 13:10 [Qemu-devel] [PATCH 0/3] file descriptor passing using getfd over QMP Corey Bryant
2012-06-04 13:10 ` [Qemu-devel] [PATCH 1/3] qmp/hmp: Add QMP getfd command that returns fd Corey Bryant
2012-06-04 14:45   ` Kevin Wolf
2012-06-04 15:57     ` Corey Bryant
2012-06-05 18:30   ` Luiz Capitulino
2012-06-06 14:04     ` Corey Bryant
2012-06-06 17:50       ` Luiz Capitulino
2012-06-06 19:42         ` Corey Bryant
2012-06-08 10:46       ` Daniel P. Berrange
2012-06-08 13:17         ` Corey Bryant
2012-06-04 13:10 ` [Qemu-devel] [PATCH 2/3] block: Add support to "open" /dev/fd/X filenames Corey Bryant
2012-06-04 14:32   ` Eric Blake
2012-06-04 15:51     ` Corey Bryant
2012-06-04 16:03       ` Eric Blake
2012-06-04 16:28         ` Corey Bryant [this message]
2012-06-04 16:36           ` Eric Blake
2012-06-04 16:40             ` Corey Bryant
2012-06-04 14:54   ` Kevin Wolf
2012-06-04 16:07     ` Corey Bryant
2012-06-04 13:10 ` [Qemu-devel] [PATCH 3/3] Sample server that opens image files for QEMU Corey Bryant
2012-06-04 15:01   ` Kevin Wolf
2012-06-04 16:15     ` Corey Bryant

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=4FCCE234.5040109@linux.vnet.ibm.com \
    --to=coreyb@linux.vnet.ibm.com \
    --cc=aliguori@us.ibm.com \
    --cc=eblake@redhat.com \
    --cc=kwolf@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=stefanha@linux.vnet.ibm.com \
    /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.