[Bug 275099] cat(1) can't read directories

2023-11-18 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=275099

Martin Matuska  changed:

   What|Removed |Added

 Status|New |In Progress
   Assignee|b...@freebsd.org|m...@freebsd.org

-- 
You are receiving this mail because:
You are the assignee for the bug.


[Bug 275099] cat(1) can't read directories

2023-11-14 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=275099

WHR  changed:

   What|Removed |Added

 Attachment #246324|text/x-c|text/x-csrc
  mime type||

-- 
You are receiving this mail because:
You are the assignee for the bug.


[Bug 275099] cat(1) can't read directories

2023-11-14 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=275099

WHR  changed:

   What|Removed |Added

 Attachment #246324|text/plain  |text/x-c
  mime type||

-- 
You are receiving this mail because:
You are the assignee for the bug.


[Bug 275099] cat(1) can't read directories

2023-11-14 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=275099

--- Comment #1 from WHR  ---
Created attachment 246325
  --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=246325=edit
Proposed fix

cat(1) should fallback to the read(2) system call if copy_file_range(2) failed
with EISDIR.

-- 
You are receiving this mail because:
You are the assignee for the bug.


[Bug 275099] cat(1) can't read directories

2023-11-14 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=275099

Bug ID: 275099
   Summary: cat(1) can't read directories
   Product: Base System
   Version: CURRENT
  Hardware: Any
OS: Any
Status: New
  Severity: Affects Only Me
  Priority: ---
 Component: bin
  Assignee: b...@freebsd.org
  Reporter: msl023...@gmail.com
 Attachment #246324 text/plain
 mime type:

Created attachment 246324
  --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=246324=edit
helloworld-dir.c

While it is not common to read(2) a directory directly, this is still supported
in FreeBSD (with security.bsd.allow_read_dir=1); and it could be actually
useful in FUSE as an user space file system implementation may provide some
data in a directory itself.

The followings demonstrate the issue with a FUSE-based file system:


# sysctl security.bsd.allow_read_dir=1
security.bsd.allow_read_dir: 0 -> 1
# helloworld-dir /mnt/3/
# ls -al /mnt/3/
total 0
drwxr-xr-x  2 root wheel 27 Jan  1  1970 .
drwxr-xr-x  2 root wheel 13 Jan  1  1970 hello
# ls -al /mnt/3/hello/
total 0
drwxr-xr-x  2 root wheel 13 Jan  1  1970 .
drwxr-xr-x  2 root wheel 27 Jan  1  1970 ..
-rw-r--r--  1 root wheel 12 Jan  1  1970 world
# cat /mnt/3/hello/world 
Hello world
# cat /mnt/3/hello
cat: stdout: Is a directory
# dd status=none if=/mnt/3/hello
Hello world!
# cat /mnt/3/
cat: stdout: Is a directory
# dd status=none if=/mnt/3/
This is the root directory
# umount /mnt/3/


It shows that cat(1) failed to read the directories but dd(1) works without
problem.

The cause is that cat(1) tries to use copy_file_range(2) to copy input file to
stdout but this system call dosen't work on directories as documented, and
cat(1) didn't fallback to read(2) and write(2) on copy_file_range(2) fail with
EISDIR.

The FUSE program for demonstration is attached.

-- 
You are receiving this mail because:
You are the assignee for the bug.