[Pvfs2-developers] File truncated on failed permissions check
carns at mcs.anl.gov
Thu May 14 16:29:51 EDT 2009
I think I understand what's going on in this case. There are actually
a) allowing truncate to proceed after the permissions are revoked
b) returning enoent when the permission check finally fails
a) is tough if the acache is enabled. The acache is not consistent
across clients. For truncate this is particularly a problem because
datafiles don't store permission and the I/O servers therefore can't do
independent permission checking. We could modify truncate to force it
to get fresh permissions before proceeding. Maybe optionally at least.
b) is a bug. That is coming from a follow up operation (setattr or
getattr) after the truncate that has its permissions checked by the
metadata server. There is a problem there in which if all permission
checks fail on the server side PVFS returns enoent:
It shouldn't be too hard to cook up a patch for each of these issues.
I'll look into it.
Bart Taylor wrote:
> Hey guys, we have run into another odd permissions case.
> The problem happens when updating a user's access to a file while it is
> still stored in another client's acache. In our test a client does an
> ls, their write permissions are removed from another client, and while
> the cache entry is still valid they try to overwrite the file. The
> result is a truncated file of zero bytes with an ENOENT return value.
> The test fails as expected and does not truncate the file if acache is
> turned off.
> Attached is a bash script that sets up the test for you, but it does
> require manually running a couple of commands at the right time on
> another client. Our clients are using an acache time out of 30 seconds.
> To run:
> Client1 - start the bash script and waith for the first prompt (
> ./perms-update-test.sh myuser mygroup /mnt/pvfs2 )
> Client2 - execute an ls in the directory passed to the script ( from
> /mnt/pvfs2: ls )
> Client1 - wait for the second prompt
> Client2 - overwrite the file (echo "text" > file1.txt)
> Client1 - check the file size if file1.txt in the output
> I also attached a server log that shows the truncate succeeding and
> immediately calling setattr which fails. The server logging was turned
> on only for the file overwrite.
> Should the server be checking the file's permissions before the truncate
> Pvfs2-developers mailing list
> Pvfs2-developers at beowulf-underground.org
More information about the Pvfs2-developers