Skip site navigation (1)Skip section navigation (2) 
Date:      Sat, 28 Nov 2020 05:26:48 +0000
From:      bugzilla-noreply@freebsd.org
To:        bugs@FreeBSD.org
Subject:   [Bug 251433] unionfs copymode transparent creates files with current euid instead of lower layer file owner uid.
Message-ID:  <bug-251433-227@https.bugs.freebsd.org/bugzilla/>
next in thread | raw e-mail | index | archive | help 
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D251433

            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@FreeBSD.org
          Reporter: raj@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=3Dtranspaent 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=3Dtransparent was working right, it would create t=
hat
copy of test-union/data on the upper layer using the owner uid "root" not
"user". But somehow it is not doing that.=20

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.=20

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

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 =3D lva->va_mode;
                uva->va_uid =3D lva->va_uid;
                uva->va_gid =3D 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.

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

Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-251433-227>