Bug 1477623

Summary: Running file API on a special chardev may hang forever
Product: [Community] Virtualization Tools Reporter: mathieu.tarral
Component: libguestfsAssignee: Richard W.M. Jones <rjones>
Status: CLOSED UPSTREAM QA Contact:
Severity: low Docs Contact:
Priority: unspecified    
Version: unspecifiedCC: ptoscano, rbalakri
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2017-08-08 17:27:09 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
Dockerfile to reproduce the issue none

Description mathieu.tarral 2017-08-02 13:37:30 UTC 
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:
Always


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

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 13:42:40 UTC 
Reproducer:

$ 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 13:44:17 UTC 
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 07:55:20 UTC 
*** Bug 1477665 has been marked as a duplicate of this bug. ***
Comment 4 Richard W.M. Jones 2017-08-03 08:00:02 UTC 
These two bugs are different aspects of the same problem.

The guestfs_file API filename parameter is marked as Dev_or_Path:
https://github.com/libguestfs/libguestfs/blob/c355b744bf22a3abc9fd289357a87c804faabc38/generator/actions_core.ml#L2104

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 17:14:27 UTC 
That was a bit harder than I thought it was going to be, but
patches posted:

https://www.redhat.com/archives/libguestfs/2017-August/msg00038.html
Comment 6 Richard W.M. Jones 2017-08-08 17:27:09 UTC 
This is fixed upstream in libguestfs >= 1.37.21.