On Fri, Oct 07, 2005 at 02:34:21PM -0400, Dave Quigley wrote: > Shaya Potter wrote: > > >unionfs_permission does this > > > >err = permission(hidden_inode, mask, nd); > >/* If the leftmost branch is r/o we can't copyup. > >* Otherwise we ignore EROFS. */ > >if (IS_COPYUP_ERR(err) && (bindex != 0)) > > err = inode_permission(hidden_inode, mask, nd); > > > >since inode_permission seems to bascially be the samething as > >permission, what exactly is the point of this? as nothing changes b/w > >the calls? > > > >_______________________________________________ > >unionfs mailing list > >[email protected] > >http://www.fsl.cs.sunysb.edu/mailman/listinfo/unionfs > > > > > > > > > Hello, > The issue that we ran into was that permission will return right > away if we are trying to request write permissions on a read only file > system. This was causing a bug where we wouldn't check the permissions > on a file if it existed on a read only file system.so what would happen > is that the file would be copied up regardless of whether the person has > the proper permissions for the file and in the case of something like > passwd or another file this would allow you to chmod or chown a file to > any user/permissions you wanted and then you could edit it as much as > you want. So what we did here is we copied the permission function but > removed the failure on erofs. This way even if its on a read only file > system we can check the actual permissions of the file to see if we > would be allowed to write to it if it weren't on a read only file system > and if we can we would then copy it up and allow the person to write to > it. Otherwise it should fail with EACCESS.
I think that Shayas point was, why we use duplicate code here. Since we cannot use the vfs permission() because of the erraneous EROFS check, we use a different permission function anyways, and could as well integrate both checks into inode_permission() instead of doing the (almost) same thing twice. Regards -Klaus Knopper _______________________________________________ unionfs mailing list [email protected] http://www.fsl.cs.sunysb.edu/mailman/listinfo/unionfs
