Date: Mon, 25 Mar 2002 16:28:36 +0100 (CET) From: BOUWSMA Beery <freebsd-user@dcf77-zeit.netscum.dyndns.dk> To: "Vladimir B. " Grebenschikov <vova@express.ru> Cc: hackers@freebsd.org Subject: Re: unionfs and getcwd problem. Message-ID: <200203251528.g2PFSaY00856@beerswilling.netscum.dyndns.dk> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
> > 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200203251528.g2PFSaY00856>