Jan Engelhardt:
> >Hi!! I just tested unionfs-20051013-1721 with the patch named too -> works
> >surprisingly well :-)
:::
> Read the readmes and look for -DNFS_SECURITY_HOLE. I think that's it.
In order to avoid confusion, I will try explain my two pathces.
1. (posted on Oct 16, which is merged as -DNFS_SECURITY_HOLE feature)
To address the problem of opening a file for write.
The higher branch is writable(any filesystem), the lower is nfs which is
exported as readonly. The parent dir of the file does not exist on the
writable branch, but exists on the nfs branch. And its permission bits
are set as writable(0755 or somethihg).
After applying the patch, unionfs ignores the response from the nfs
server EACCES and believes the result of test of the dir's
mode(permission bits).
2. (posted on Oct 7 and 5)
To address the problem of writing a dir, which means deleting or
creating a file or a dir under the dir.
The higher branch is writable(any filesystem), the lower is readonly or
readwrite any filesystem. The dir exists on both branches but the
permission bits are different. The dir on the writable branch, its mode
is set as writable. On the lower branch, the dir's mode is set
readonly(0555 or something).
After applying the patch, unionfs does not test the dir on lower branch
and believes the result of the higher branch.
I'm not sure which is effective to Dirk's case.
Junjiro Okajima
_______________________________________________
unionfs mailing list
[email protected]
http://www.fsl.cs.sunysb.edu/mailman/listinfo/unionfs
