Date: Sat, 28 Nov 2020 05:46:15 +0000 From: bugzilla-noreply@freebsd.org To: bugs@FreeBSD.org Subject: [Bug 251363] use unionfs as a disk-cache for NFS [feature] Message-ID: <bug-251363-227-xqY8umM5UZ@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-251363-227@https.bugs.freebsd.org/bugzilla/> References: <bug-251363-227@https.bugs.freebsd.org/bugzilla/>
index | next in thread | previous in thread | raw e-mail
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=251363 Gunther Schadow <raj@gusw.net> changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://bugs.freebsd.org/bu | |gzilla/show_bug.cgi?id=2514 | |33 --- Comment #14 from Gunther Schadow <raj@gusw.net> --- Cross referencing the bug 251433 I just filed, since that is in fact a real bug. The question is does it really matter to me? What is my workaround? Clearly I need to be able to make the copy on the upper layer. And it is root that must make that copy. The effective user id to decide if the VOP_CREATE is allowed must be root, or whatever user did the mount_unionfs. Not the user accessing the file right now. The owner uid and gid should be exactly that from the lower layer. Not the euid of the user accessing the file. I need to understand how this VOP_CREATE ultimately works. Note that it seems to work right with the shadow directories. So that might be a clue. -- You are receiving this mail because: You are the assignee for the bug.help
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-251363-227-xqY8umM5UZ>