Re: unionfs and getcwd problem.
On Mon, 2002-03-25 at 18:28, BOUWSMA Beery wrote: 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. May be you will be interested in -o union flag to any standart mount It works a bit different from special union FS. thanks, barry bouwsma -- TSB Russian Express, Moscow Vladimir B. Grebenschikov, [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: unionfs and getcwd problem.
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][EMAIL PROTECTED]:/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 wheel194 Jan 24 22:37 Makefile
drwxr-xr-x 7 root wheel512 Mar 25 10:03 ..
drwxr-xr-x 7 root wheel512 Mar 25 10:03 ..
-rw-r--r-- 1 root wheel 4918 Mar 25 10:05 splash_bmp.c-patch
drwxr-xr-x 4 root wheel512 Mar 25 10:05 .
drwxr-xr-x 4 root wheel512 Mar 25 10:05 .
contents of nullfs-remounted (original) dir:
[10:08:19][EMAIL PROTECTED]:/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 wheel512 Nov 23 00:21 ..
drwxr-xr-x 2 root wheel512 Jan 24 22:37 .
-rw-r--r-- 1 root wheel194 Jan 24 22:37 Makefile
Contents of unionfs atop that:
[10:05:59][EMAIL PROTECTED]:/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 wheel512 Mar 25 10:03 ..
-rw-r--r-- 1 root wheel 4918 Mar 25 10:05 splash_bmp.c-patch
drwxr-xr-x 2 root wheel512 Mar 25 10:05 .
Attempt to use patch:
[10:07:00][EMAIL PROTECTED]:/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
|+++
Re: unionfs and getcwd problem.
On Mon, 2002-03-11 at 00:47, BOUWSMA Beery wrote: Thanks! I'm pleased to report that I applied your patch to my -stable source, and now I'm able to `make buildworld' with my rw unionfs mount of my local hacks, atop a ro nullfs mount with unaltered source, which I'm doing right now. 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. One of possible workarounds do as root find /union/mount/point to create all shadow directories. 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) thanks, barry bouwsma -- TSB Russian Express, Moscow Vladimir B. Grebenschikov, [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: unionfs and getcwd problem.
[replies sent directly to me may timeout and bounce, since I'm not
online as often as I should be, but I'll check the list archives]
Moin, moin!
%s wrote on %.3s, %lld Sep 1993
On Mon, 2002-02-25 at 17:35, Takanori Watanabe wrote:
Hi, I had trouble with unionfs when it calles getcwd(3) when
I mount some directory on the directry in same file system,like
mount -t union /usr/home/foo/bar /usr/src/sys/ .
[...]
so it failed to recognize mount point. So I tried the patch as
follows taken from nullfs. Are there any problem with this patch?
Thanks! I'm pleased to report that I applied your patch to my
-stable source, and now I'm able to `make buildworld' with my
rw unionfs mount of my local hacks, atop a ro nullfs mount with
unaltered source, which I'm doing right now.
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.:
| bash-2.05a$ ls -l /usr/src/sys/boot/
| ls: alpha: Permission denied
| ls: arc: Permission denied
| ls: forth: Permission denied
| ls: pc98: Permission denied
| total 20
| -rw-r--r-- 1 root wheel516 Nov 15 1999 Makefile
| -rw-r--r-- 1 root wheel 11542 Jul 7 2000 README
| drwxr-xr-x 4 root wheel512 Mar 9 17:15 common
[...]
patch below will turn on caching on unionfs, and solve getcwd problem,
patch against -CURRENT
+ if ((error == 0 || error == ENOENT) saveflags MAKEENTRY
cnp-cn_nameiop != CREATE) {
This apparently doesn't want to work for -stable, with `saveflags'
causing a problem. Once I finish my -stable build, I'll see how
this changes the behaviour in -current. Thanks!
-*-
Hmmm, it has the same `saveflags' problem with my -current (from a few
days ago). Also, the first patch above, which worked well for me in
-stable, also seems to work for the getcwd() problem (csh, make) in
-current, but two minor problems remain --
* non-r00t users get errors as in -stable for missing directories
ls: share: Permission denied
ls: tools: Permission denied
ls: usr.bin: Permission denied
* existing directories show up twice in -current (not a problem
with -stable) with `ls -li' here:
41032 drwxr-xr-x 53 root wheel512 Mar 10 22:22 sys
41032 drwxr-xr-x 53 root wheel512 Mar 10 22:22 sys
41029 drwxr-xr-x 164 root wheel512 Dec 27 03:10 usr.sbin
41029 drwxr-xr-x 164 root wheel512 Dec 27 03:10 usr.sbin
(heh, I haven't checked to see how identical files in both layers
are handled)
Also, this is a unionfs mount atop a nullfs mount within the same
filesystem, /usr, /usr/local/system/src nullfs atop /usr/src, with
/usr/local/source-hacks unionfs atop the nullfs /usr/src, if it matters.
thanks,
barry bouwsma
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
Re: unionfs and getcwd problem.
Takanori Watanabe [EMAIL PROTECTED] wrote: Hi, I had trouble with unionfs when it calles getcwd(3) when I mount some directory on the directry in same file system,like mount -t union /usr/home/foo/bar /usr/src/sys/ . I investigate the problem by inserting debug print in getcwd.c. Then I found issuing __getcwd(2) in getcwd(3) failed, and climb up filesystem tree as the next way. But it failed when it reaches to mount point. It seems that st_dev and st_ino member returns the same number as the underlying filesystem so it failed to recognize mount point. So I tried the patch as follows taken from nullfs. Are there any problem with this patch? It looks fine to me. I know you definitely need to provide this behavior when doing a wrapper filesystem to behave like the system's stat() :) Takanori Watanabe a href=http://www.planet.sci.kobe-u.ac.jp/~takawata/key.html; Public Key/a Key fingerprint = 2C 51 E2 78 2C E1 C5 2D 0F F1 20 A3 11 3A 62 2A --- union_vnops.c~Tue Oct 2 00:01:37 2001 +++ union_vnops.c Mon Feb 25 22:44:51 2002 @@ -957,6 +957,8 @@ union_newsize(ap-a_vp, VNOVAL, vap-va_size); } + ap-a_vap-va_fsid = ap-a_vp-v_mount-mnt_stat.f_fsid.val[0]; + if ((vap != ap-a_vap) (vap-va_type == VDIR)) ap-a_vap-va_nlink += vap-va_nlink; return (0); -- Brian Fundakowski Feldman \'[ FreeBSD ]''\ [EMAIL PROTECTED] [EMAIL PROTECTED] \ The Power to Serve! \ Opinions expressed are my own. \,,\ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
unionfs and getcwd problem.
Hi, I had trouble with unionfs when it calles getcwd(3) when I mount some directory on the directry in same file system,like mount -t union /usr/home/foo/bar /usr/src/sys/ . I investigate the problem by inserting debug print in getcwd.c. Then I found issuing __getcwd(2) in getcwd(3) failed, and climb up filesystem tree as the next way. But it failed when it reaches to mount point. It seems that st_dev and st_ino member returns the same number as the underlying filesystem so it failed to recognize mount point. So I tried the patch as follows taken from nullfs. Are there any problem with this patch? Takanori Watanabe a href=http://www.planet.sci.kobe-u.ac.jp/~takawata/key.html; Public Key/a Key fingerprint = 2C 51 E2 78 2C E1 C5 2D 0F F1 20 A3 11 3A 62 2A --- union_vnops.c~ Tue Oct 2 00:01:37 2001 +++ union_vnops.c Mon Feb 25 22:44:51 2002 @@ -957,6 +957,8 @@ union_newsize(ap-a_vp, VNOVAL, vap-va_size); } + ap-a_vap-va_fsid = ap-a_vp-v_mount-mnt_stat.f_fsid.val[0]; + if ((vap != ap-a_vap) (vap-va_type == VDIR)) ap-a_vap-va_nlink += vap-va_nlink; return (0); To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
