Bug 1477623 - Running file API on a special chardev may hang forever
Running file API on a special chardev may hang forever
Product: Virtualization Tools
Classification: Community
Component: libguestfs (Show other bugs)
Unspecified Linux
unspecified Severity low
: ---
: ---
Assigned To: Richard W.M. Jones
: 1477665 (view as bug list)
Depends On:
  Show dependency treegraph
Reported: 2017-08-02 09:37 EDT by mathieu.tarral
Modified: 2017-08-08 13:27 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2017-08-08 13:27:09 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
Dockerfile to reproduce the issue (658 bytes, text/plain)
2017-08-02 09:37 EDT, mathieu.tarral
no flags Details

  None (edit)
Description mathieu.tarral 2017-08-02 09:37:30 EDT
Created attachment 1308246 [details]
Dockerfile to reproduce the issue

Description of problem:

When you try to run the file tool on special chardevices like /dev/console or /dev/tty on your machine, it works fine.
For example it reports the following output:

$ file /dev/console
/dev/console: character special (5/1)

$ file /dev/tty
/dev/tty: character special (5/0)

But using libguestfs, it somehow hangs, and it don't see why, as it should just run the file tool and returns the output i guess ??

-> libguestfs hangs forever

Version-Release number of selected component (if applicable):
latest available on Ubuntu 16.04

How reproducible:

Steps to Reproduce:
1. mount the filesystem in libguestfs
2. using the python API run g.file('/dev/console')

Actual results:
libguestfs hangs

Expected results:
libguestfs should return /dev/console: character special (5/1)

Additional info:

I provided a Dockerfile for you to reproduce the issue.
You can take it from here : https://gist.github.com/Wenzel/09b222f3572fa34ec01b50f69c5a556e

1. docker build -t libguestfs-bug-file .
2. docker run --rm -it libguestfs-bug-file

Running it will drop you into a ipython shell with libguestfs initialized and a image is already mounted.

Just run:
[1] g.file('/dev/console')

Thanks a lot !
Comment 1 Richard W.M. Jones 2017-08-02 09:42:40 EDT

$ virt-builder fedora-26
$ guestfish -a fedora-26.img -i
><fs> mknod-c 0777 5 1 /dev/console
><fs> ll /dev
total 0
drwxr-xr-x.  2 root root   21 Aug  2 13:41 .
dr-xr-xr-x. 17 root root  224 Jul 19 14:39 ..
crwxr-xr-x   1 root root 5, 1 Aug  2 13:41 console

><fs> file /dev/console
[hangs here]

Reproducible for me in libguestfs-1.36.5-1.fc26.x86_64
Comment 2 Richard W.M. Jones 2017-08-02 09:44:17 EDT
Also reproducible with libguestfs from git (with the OCaml API).

Grrr I thought we'd fixed this bug years ago :-(
Comment 3 Richard W.M. Jones 2017-08-03 03:55:20 EDT
*** Bug 1477665 has been marked as a duplicate of this bug. ***
Comment 4 Richard W.M. Jones 2017-08-03 04:00:02 EDT
These two bugs are different aspects of the same problem.

The guestfs_file API filename parameter is marked as Dev_or_Path:

This is supposed to allow you to do g.file ("/dev/sda1") and have it
do the obvious thing.

This is implemented by looking at the appliance device node if we think
the parameter corresponds to a device.

However the stub code in the daemon only checks if the path begins with
"/dev/", which is not very clever.  It should really check if the path
corresponds to the name of an appliance block device (possibly untranslated).

In any case I wouldn't try using guestfs_file on /dev/ paths.  Even if
we fix this problem it won't return any useful information because the
implementation simple returns fixed strings like "block device" etc for
anything which is a block device etc.  It's probably better to use g.statns()
first and only call g.file() for regular files which don't begin with "/dev/".
Comment 5 Richard W.M. Jones 2017-08-03 13:14:27 EDT
That was a bit harder than I thought it was going to be, but
patches posted:

Comment 6 Richard W.M. Jones 2017-08-08 13:27:09 EDT
This is fixed upstream in libguestfs >= 1.37.21.

Note You need to log in before you can comment on or make changes to this bug.