|
Description
|
[mws, 18Feb2008]
I've discovered an odd discrepancy in the ZFS versus legacy filesystem
semantics with respect to what privilege bits are required. Specifically,
if a process has file_dac_write, but *not* file_dac_read, and a file of
mode 0644 not owned by that process's UID is opened O_RDWR, both tmpfs and
ufs permit this to happen, but zfs fails with EACCES citing file_dac_read.
Here's an example of how to make this happen:
First become root and remove file_dac_read from your permission set:
$ su
Password:
# ppriv -s A-file_dac_read $$
In tmpfs, create the file, set the modes, and watch the open O_RDWR succeed:
# cd /tmp
# df .
/tmp (swap ): 162200 blocks 561363 files
# touch file
# chown dladm:sys file
# chmod 0644 file
# truss -t open ksh -c 'date <>file'
open("/var/ld/ld.config", O_RDONLY) Err#2 ENOENT
open("/lib/libc.so.1", O_RDONLY) = 3
open64("file", O_RDWR|O_CREAT, 0666) = 3
...
Now repeat experiment from same shell without file_dac_read in ZFS:
# cd /
# df .
/ (system/root ):419914921 blocks 419914921 files
# touch file
# chown dladm:sys file
# chmod 0644 file
# truss -t open ksh -c 'date <>file'
open("/var/ld/ld.config", O_RDONLY) Err#2 ENOENT
open("/lib/libc.so.1", O_RDONLY) = 3
open64("file", O_RDWR|O_CREAT, 0666) Err#13 EACCES [file_dac_read]
ksh: file: cannot create
This may sound like a very odd edge case, but I ran into this because the newly
introduced dlmgmtd(1M) daemon executes with exactly this behavior, and thus
cannot function on a ZFS root filesystem, meaning networking becomes quite broken.
|