[Bug 213714] getcwd(3) returns EACCES on ZFS when normalization is not none and any parent dir does not have read permission

bugzilla-noreply at freebsd.org bugzilla-noreply at freebsd.org
Sun Oct 23 03:48:33 UTC 2016


https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=213714

            Bug ID: 213714
           Summary: getcwd(3) returns EACCES on ZFS when normalization is
                    not none and any parent dir does not have read
                    permission
           Product: Base System
           Version: 11.0-STABLE
          Hardware: amd64
                OS: Any
            Status: New
          Severity: Affects Many People
          Priority: ---
         Component: kern
          Assignee: freebsd-bugs at FreeBSD.org
          Reporter: cynix at me.com
                CC: freebsd-amd64 at FreeBSD.org
                CC: freebsd-amd64 at FreeBSD.org

On 11.0-RELEASE-p1, getcwd(3) returns EACCES under the following conditions:

* Current directory is under a ZFS filesystem (seems to also affect other
filesystems mounted under ZFS root).
* The ZFS dataset's "normalization" property is not "none" (can be any of
formC/formD/formKC/formKD).
* Any parent directory in the path does not have read permission for the user.

Whereas on 10.3 (I have tested 10.3-RELEASE-p5 and earlier) it would succeed
and populate the correct full path.

For example:

# zfs create -o normalization=formD z/test1
# mkdir -m711 /test1/foo
# mkdir /test1/foo/bar
# chown nobody /test1/foo/bar
# cd /test1/foo/bar
# su -m nobody
% /bin/pwd
pwd: .: Permission denied

The problem does not occur if normoalization is none:

# zfs create -o normalization=none z/test2
# mkdir -m711 /test2/foo
# mkdir /test2/foo/bar
# chown nobody /test2/foo/bar
# cd /test2/foo/bar
# su -m nobody
% /bin/pwd
/test2/foo/bar

It seems that zfs_acl_next_ace() for the parent dir returns an access_mask of
0x1200af when normalization is none, and 0x1200a8 otherwise, all else being
equal.

-- 
You are receiving this mail because:
You are on the CC list for the bug.


More information about the freebsd-amd64 mailing list