[Bug 251433] unionfs copymode transparent creates files with current euid instead of lower layer file owner uid.

[bugzilla-noreply at freebsd.org]

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

            Bug ID: 251433
           Summary: unionfs copymode transparent creates files with
                    current euid instead of lower layer file owner uid.
           Product: Base System
           Version: 12.2-RELEASE
          Hardware: Any
                OS: Any
            Status: New
          Severity: Affects Some People
          Priority: ---
         Component: kern
          Assignee: bugs at FreeBSD.org
          Reporter: raj at gusw.net

Test:
-1. as root -------------------------------------------------------

cd /tmp
mkdir test-upper
mkdir test-union
echo "I'm root!" > test-union/data
chmod 755 test-*
chown -R root:wheel test-*
chmod 664 test-*

mount -t unionfs -o copymode=transpaent test-upper test-union

-2. as another user in group wheel ---------------------------------

cd /tmp
cat test-union/data
# I'm root!
ls -l test-union/data
# -rw-rw-r-- root wheel 10 test-union/data
echo "But I'm not root!" > test-union/data
cat test-union/data
# But I'm not root!
ls -l test-union/data
# -rw-rw-r-- user wheel 18 test-union/data

rm test-upper/data
cat test-union/data
# I'm root!
ls -l test-union/data
# -rw-rw-r-- root wheel 10 test-union/data
----------------------------------------------------------------------

You see, if the copymode=transparent was working right, it would create that
copy of test-union/data on the upper layer using the owner uid "root" not
"user". But somehow it is not doing that. 

And just to be clear, a simple overwrite of an existing file by an euid
different from the owener uid does not change the owner uid. 

So this is a bug, but it's complicated, because the code says very clearly 

Out of unionfs_subr.c

unionfs_copyfile(...) calls
unionfs_vn_create_on_upper(...) calls
unionfs_create_uppervattr_core(...) does

        case UNIONFS_TRANSPARENT:
                uva->va_mode = lva->va_mode;
                uva->va_uid = lva->va_uid;
                uva->va_gid = lva->va_gid;
                break;

which uva is then used in the VOP_CREATE call.

What could the problem be here? Something is apparently "correcting" the
uva->va_unid setting between here and the final effect of VOP_CREATE.

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