On Tue, Sep 27, 2005 at 11:19:24AM +0200, Martin Walter wrote:
> > I'm not sure if this is the problem, but this behaviour SHOULD be
> > absolutely correct if you exported the NFS filesystem without
> > "no_root_squash". The root UID on the lcal system is mapped to "nobody"
> > on the remote filesystem, so a permission() call SHOULD say that root
> > ("nobody" on the remote system) has NO PERMISSION to modify that file!
>
> Sorry, I do not agree. If you check on the server which exports readonly
> a tree, it will (hopefully ;-) reject any writes regardless "no_root_squash".
That was a problem with the old code. If the branch where the file (or a
directory in which you wanted to create a new file) was located on a
read-only branch (NFS or not), permission() from the VFS ALWAYS returned
-EROFS, regardless of the file or directories real permission, and the
unionfs code "fixed" that by assuming that any user can always write on
the read-writebranch, hence ignoring the permission() result in this
case.
So, it was always "OK" to overwrite /etc/passwd as a normal user, as
long as the original file was on a read-only file system. Which is of
course terribly wrong.
My patch just removed the check for ROFS in the vfs permission() call,
which results in a real check of the file or directories permission.
So, if you could, oermission-wise, write to the file if the branch was
mounted read-write, then and only then, writing to the file on the rw
branch is possible.
> But in my case that is not the question because the tree *is* exported
> with "no_root_squash".
Then something else must be wrong. Did you check if writing/touching a
file is possible if you directly write to the RW mountes NFS tree? If
that is possible, it should also be possible to do this with unionfs on
a second branch.
> > Now you mounted a local filesystem over the NFS volume. Still, the
> > permissions of the ORIGINAL file must be checked in order to find out if
> > the user has permission to create a file on the writable branch.
>
> But it should be checked out of the local clients view.
The local client should check the permission of the file or directory in
question for write permissions, NFS or not. If over unionfs you couly
ALWAYS write to ANY file until it is copied to the upper layer, you make
a kind of DOS file system out of the formerly secure Unix file system,
where any user can overwrite any file (once). This cannot be the
intention.
But if in your example, you could indeed write to the rw mounted NFS
branch (without unionfs), and you can't write to a union containing that
branch, then I agree that something is wrong. Maybe there is an
additional, NFS-related check in generic_permission() which must be
ignored, like I did with the EROFS that was overwriting the real
permission check. Then we would maybe also need a rewritten
generic_permission call.
Regards
-Klaus Knopper
_______________________________________________
unionfs mailing list
unionfs@mail.fsl.cs.sunysb.edu
http://www.fsl.cs.sunysb.edu/mailman/listinfo/unionfs
