Bug 13483 - pseudo prevents using /dev/fd/*
Summary: pseudo prevents using /dev/fd/*
Status: RESOLVED DUPLICATE of bug 13288
Alias: None
Product: Pseudo
Classification: Yocto Project Subprojects
Component: pseudo (show other bugs)
Version: master
Hardware: x86 x86_64
: Medium+ major
Target Milestone: 2.8 M4
Assignee: Seebs
QA Contact:
URL:
Whiteboard:
Depends on:
Blocks:
 
Reported: 2019-08-14 20:46 UTC by Sam Liddicott
Modified: 2019-08-15 15:44 UTC (History)
3 users (show)

See Also:
OS type for building Yocto: ---
Type of Regression: ---
Verified:
Documentation change: No (bug/feature does not impact docs)


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Sam Liddicott 2019-08-14 20:46:04 UTC
pseudo insists on dereferencing /proc/*/fd/* filenames which means that /dev/fd/62 or /proc/$$/fd/62 or /proc/self/fd/62 don't work.

This means the pseudo environment can break any program or script that depends on /dev/fd/* working

I think the easiest fix is to attempt to open the last symlink where lstat worked, not the one where it doesn't work.

This example works under normal system or with fakeroot, but fails under pseudo:

bash -c 'cat <( echo hello )'

strace shows what is going on:

bash -c 'strace -f cat <( echo hello )'

without pseudo (or even just using fakeroot), it's as simple as:

openat(AT_FDCWD, "/dev/fd/63", O_RDONLY) = 3


but with pseudo we get this link de-referencing and failure:


lstat("/dev", {st_mode=S_IFDIR|0755, st_size=4040, ...}) = 0

lstat("/dev/fd", {st_mode=S_IFLNK|0777, st_size=13, ...}) = 0

rt_sigprocmask(SIG_BLOCK, [HUP USR1 USR2 ALRM TERM CHLD], [HUP USR1 USR2 ALRM TERM CHLD], 8) = 0

readlink("/dev/fd", "/proc/self/fd", 4096) = 13

rt_sigprocmask(SIG_SETMASK, [HUP USR1 USR2 ALRM TERM CHLD], NULL, 8) = 0

lstat("/proc", {st_mode=S_IFDIR|0555, st_size=0, ...}) = 0

lstat("/proc/self", {st_mode=S_IFLNK|0777, st_size=0, ...}) = 0

rt_sigprocmask(SIG_BLOCK, [HUP USR1 USR2 ALRM TERM CHLD], [HUP USR1 USR2 ALRM TERM CHLD], 8) = 0

readlink("/proc/self", "6724", 4096)    = 4

rt_sigprocmask(SIG_SETMASK, [HUP USR1 USR2 ALRM TERM CHLD], NULL, 8) = 0

lstat("/proc/6724", {st_mode=S_IFDIR|0555, st_size=0, ...}) = 0

lstat("/proc/6724/fd", {st_mode=S_IFDIR|0500, st_size=0, ...}) = 0

lstat("/proc/6724/fd/63", {st_mode=S_IFLNK|0500, st_size=64, ...}) = 0

rt_sigprocmask(SIG_BLOCK, [HUP USR1 USR2 ALRM TERM CHLD], [HUP USR1 USR2 ALRM TERM CHLD], 8) = 0

readlink("/proc/6724/fd/63", "pipe:[21346885]", 4096) = 15

rt_sigprocmask(SIG_SETMASK, [HUP USR1 USR2 ALRM TERM CHLD], NULL, 8) = 0

lstat("/proc/6724/fd/pipe:[21346885]", 0x7ffe0f16e040) = -1 ENOENT (No such file or directory)

newfstatat(AT_FDCWD, "/proc/6724/fd/pipe:[21346885]", 0x7ffe0f16e080, 0) = -1 ENOENT (No such file or directory)

openat(AT_FDCWD, "/proc/6724/fd/pipe:[21346885]", O_RDONLY) = -1 ENOENT (No such file or directory)
Comment 1 Sam Liddicott 2019-08-15 05:28:10 UTC
NOTE: it is pipe and socket fd's that fail to open under linux because they appear to be dangling symlinks, but the kernel successfully opens them anyway
Comment 2 Randy MacLeod 2019-08-15 14:49:28 UTC
Seebs, should this work under pseudo?
Comment 3 Seebs 2019-08-15 15:44:20 UTC
This looks to be the same underlying issue as 13288.

*** This bug has been marked as a duplicate of bug 13288 ***