From owner-freebsd-hackers Mon Mar 25 7:28:53 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from dastardly.newsbastards.org.72.27.172.IN-addr.ARPA.NetScum.dyndns.dk (dclient217-162-214-218.hispeed.ch [217.162.214.218]) by hub.freebsd.org (Postfix) with ESMTP id B953337B400 for ; Mon, 25 Mar 2002 07:28:42 -0800 (PST) Received: from beerswilling.netscum.dyndns.dk (dcf77-zeit.netscum.dyndns.dk [172.27.72.27] (may be forged)) by dastardly.newsbastards.org.72.27.172.IN-addr.ARPA.NetScum.dyndns.dk (8.11.6/8.11.6) with ESMTP id g2PFSbE00857 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified FAIL); Mon, 25 Mar 2002 16:28:40 +0100 (CET) (envelope-from bounce@netscum.dyndns.dk) Received: (from root@localhost) by beerswilling.netscum.dyndns.dk (8.11.6/8.11.6) id g2PFSaY00856; Mon, 25 Mar 2002 16:28:36 +0100 (CET) (envelope-from bounce@netscum.dyndns.dk) Date: Mon, 25 Mar 2002 16:28:36 +0100 (CET) Message-Id: <200203251528.g2PFSaY00856@beerswilling.netscum.dyndns.dk> From: BOUWSMA Beery Organization: Men not wearing any pants that dont shave Subject: Re: unionfs and getcwd problem. To: "Vladimir B. " Grebenschikov Cc: hackers@freebsd.org References: <200202251435.XAA91094@shidahara1.planet.sci.kobe-u.ac.jp> <1015415443.3157.2.camel@vbook.express.ru> <200203102147.g2ALlDw00249@beerswilling.netscum.dyndns.dk> <1016041015.748.56.camel@vbook.express.ru> X-Hacked: via telnet to your port 25, what else? X-Internet-Access-Provided-By: Electromagnetics and Technological Advancements X-NetScum: Yes X-One-And-Only-Real-True-Fluffy: No Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > > The only obvious `problem' is when a non-r00t user attempts to > > access the union-mounted fs when the shadow directories have not > > yet been created, and `permission denied' is returned for all > > directories that exist below, but not in the unionfs fs. E.g.: > Yes, it is because of feature of unionfs to create shadow directories > with credentionals of proceses doing "rise" operation. > > And if process have no permissions to write into parent directory > operation fail. I have thought about what is best to do in a case like this. At first, I was thinking that if a directory like this does not presently exist in the upper (unionfs) layer, then for the case of a read-only operation like `ls', simply fall through to display what is present in the lower layer. This, if it is possible (I have no idea; I'm no hacker), would avoid the ``hey, why can't I do a simple `ls'?!?'' type of question. Of course, there would be a problem when some actual writes need to be performed in the unionfs layer. For example, suppose the ownerships in a directory path are something like mountpoint/root/r00t/user/FILE and the user is then able to `ls' all the directories down to the one s/he owns, seeing the contents of the lower layer, but then, due to being unable to create the r00t-owned directories in the path that do not yet exist in the upper unionfs layer, any attempt to do `work' in the user-owned directory will fail. So you just get the same sort of questions, only later. ``I have permission, why do I get permission denied?!?'' I do not know if this is even possible in the case of a command or operation that needs not modify the contents of the unionfs later, because I do not know the details of the internals of what happens, so I could be completely wrong to suggest this. > Another solution is to change behaviour of unionfs to use root-cred > while make shadows, and then put attributes/ownership from lower layer > to shadows. > (but this will take a bit of kernel hacking) This is another thing that I have wondered if it could be done. As it is, one of the `quirks' about the shadow directories, is that they get created with the timestamps of the first access which required their creation, and not the timestamps of the underlying filesystem. This can be both a bug and a feature, because it can be used to see immediately when a union-mounted directory was created when looking at a filesystem, when this is useful. On the other hand, the actual attributes of the underlying directory may easily change while the unionfs-mounted shadow gets unchanged, and this change may not be visible to the user. I will be quiet now, because I don't know of what I speak. Anyway, I just did a few more things on a slightly-older -current, built 07.Mar (sorry, I've had no time...), with a unionfs mount atop a read-only nullfs mount, and I do in fact see a problem with files present in both the upper and lower layer, just as I saw the duplicate directories shown by `ls'. Also, certain commands that work on a file only present in the lower layer fail until the file in question has been touched into the unionfs layer, with -current (I don't remember if this was a -stable problem too). This may be well-known and already-solved because I am almost three weeks out of date; if so, sorry. Here are the notes I made about this: unionfs mounted dir atop nullfs dir [10:06:25]root@dastardly.newsbastards.org:/usr/src/sys/modules/splash/bmp{535}# ls -lart total 52 -rw-r--r-- 1 root wheel 17634 Mar 6 2001 splash_bmp.c -rw-r--r-- 1 root wheel 17634 Mar 6 2001 splash_bmp.c-DIST -rw-r--r-- 1 root wheel 194 Jan 24 22:37 Makefile drwxr-xr-x 7 root wheel 512 Mar 25 10:03 .. drwxr-xr-x 7 root wheel 512 Mar 25 10:03 .. -rw-r--r-- 1 root wheel 4918 Mar 25 10:05 splash_bmp.c-patch drwxr-xr-x 4 root wheel 512 Mar 25 10:05 . drwxr-xr-x 4 root wheel 512 Mar 25 10:05 . contents of nullfs-remounted (original) dir: [10:08:19]root@dastardly.newsbastards.org:/usr/src/sys/modules/splash/bmp{543}# ls -lart /usr/local/system/src/sys/modules/splash/bmp/ total 24 -rw-r--r-- 1 root wheel 17634 Mar 6 2001 splash_bmp.c drwxr-xr-x 4 root wheel 512 Nov 23 00:21 .. drwxr-xr-x 2 root wheel 512 Jan 24 22:37 . -rw-r--r-- 1 root wheel 194 Jan 24 22:37 Makefile Contents of unionfs atop that: [10:05:59]root@dastardly.newsbastards.org:/usr/local/source-hacks/sys/modules/splash/bmp{533}# ls -lart total 28 -rw-r--r-- 1 root wheel 17634 Mar 6 2001 splash_bmp.c-DIST drwxr-xr-x 3 root wheel 512 Mar 25 10:03 .. -rw-r--r-- 1 root wheel 4918 Mar 25 10:05 splash_bmp.c-patch drwxr-xr-x 2 root wheel 512 Mar 25 10:05 . Attempt to use patch: [10:07:00]root@dastardly.newsbastards.org:/usr/src/sys/modules/splash/bmp{539}# patch < splash_bmp.c-patch Hmm... Looks like a unified diff to me... The text leading up to this was: -------------------------- |--- /FreeBSD-4/usr/local/source-hacks/sys/modules/splash/bmp/splash_bmp.c-DIST Tue Oct 31 09:00:06 2000 |+++ /FreeBSD-4/usr/local/source-hacks/sys/modules/splash/bmp/splash_bmp.c Mon Mar 18 12:48:48 2002 -------------------------- Patching file splash_bmp.c using Plan A... Hunk #1 succeeded at 73. Hunk #2 succeeded at 258. Hunk #3 succeeded at 274. Hunk #4 succeeded at 333. Hunk #5 succeeded at 635. Can't backup splash_bmp.c, output is in /tmp/patchor9qv12: Permission denied done Works after `touch' of file present in lower layer, but not yet in top layer: [10:07:10]root@dastardly.newsbastards.org:/usr/src/sys/modules/splash/bmp{541}# touch splash_bmp.c [10:08:17]root@dastardly.newsbastards.org:/usr/src/sys/modules/splash/bmp{542}# ls -lart total 70 -rw-r--r-- 1 root wheel 17634 Mar 6 2001 splash_bmp.c-DIST -rw-r--r-- 1 root wheel 194 Jan 24 22:37 Makefile drwxr-xr-x 7 root wheel 512 Mar 25 10:03 .. drwxr-xr-x 7 root wheel 512 Mar 25 10:03 .. -rw-r--r-- 1 root wheel 4918 Mar 25 10:05 splash_bmp.c-patch -rw-r--r-- 1 root wheel 17634 Mar 25 10:08 splash_bmp.c -rw-r--r-- 1 root wheel 17634 Mar 25 10:08 splash_bmp.c drwxr-xr-x 4 root wheel 512 Mar 25 10:08 . drwxr-xr-x 4 root wheel 512 Mar 25 10:08 . Note duplicated file too. thanks, barry bouwsma To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message