On Wed, 2005-10-05 at 00:23 +0900, [EMAIL PROTECTED] wrote:
> Shaya Potter:
> > if you create a new directory, such that it's opaque, you can't then in
> > the future delete it, as the directory isn't empty and the opaque file
> > isn't deleted.
> >
> > I think readdir_util_callback() might be getting confused
> > by .wh.__dir_opaque.
>
> I think it is a problem of unionfs_permission().
> When the target dir is on both rw and ro branches, it checks the dir on
> rw first, then on ro. Second time it gets EPERM and returns. I saw it
> under the environemnt of unionfs-20040929-0844/linux-2.6.13.2/iso9660/tmpfs.
> When the target is a file, unionfs_permission() returns after checking
> rw branch.
> I dont know why unionfs_permission() needs to check the second hidden
> entry.
It is an interesting question, but here is the rational. If we don't
check the permissions for the second branch, then the user gets
permissions that they didn't otherwise have. For example, lets assume
that we have the following:
b0/d 0755
Contains "a", "b" and "c"
b1/d 0700
Contains "d", "e", and "f"
Should we return the "d", "e" and "f" in addition to "a", "b", and "c"?
Doing so would violate the permissions on b1/d. As it turns out,
Unionfs is really used as a COW file system, so it might make sense to
treat the higher level permissions as authoritative.
Charles
_______________________________________________
unionfs mailing list
[email protected]
http://www.fsl.cs.sunysb.edu/mailman/listinfo/unionfs
