Sam Lang wrote:
There were some bugs in that patch, yeah. I've attached another patch
that fixes them. Even without the patch, tacl_xattr.sh reports
failures, but now the failures with and without the patch are the
same. I've attached the output of the tacl script for with and without
the patch cases. Do you get those failures?
As a side note, it looks like there are still some noisy messages
coming from the kernel related to ACLs regardless of whether the
patches are applied or not. The tacl_xattr.sh script generates
several of these in dmesg for me:
pvfs2_acl_chmod: get acl (access) failed with 0
They also pop out during LTP test runs.
Attached patch should also fix those. I think the error checking was
just a little bit wrong.
Hi Sam,
The patch you sent does correct both the tacl test failures and the
dmesg output for me. Thanks!
I attached the output that I see from tacl_xattr.sh; I do not get any of
the failures that you see on your end. It must be a kernel difference?
My test run was with the stock cvs trunk plus your callout patch. It
was run on a box with a RHEL4 2.6.9.x kernel.
It seems like Murali saw some differences in the acl test results too,
but I don't know if we ever completely resolved them...
-Phil
SUCCESS: Create file denied by file permission bits [ Physical directory ]
SUCCESS: Create file denied by file permission bits [ Symlink directory ]
SUCCESS: ACL_USER_OBJ entry contains the owner execute permissions,
operation success [ Physical Directory ]
SUCCESS: ACL_USER_OBJ entry contains the owner execute permissions,
operation success [ Symlink Directory ]
SUCCESS: ACL_USER_OBJ entry contains the owner write permissions,
operation success [ Physical Directory ]
SUCCESS: ACL_USER_OBJ entry contains the owner write permissions,
operation success [ Symlink Directory ]
SUCCESS: ACL_USER entry contains the user permissions,
operation success [ Physical Directory ]
SUCCESS: ACL_USER entry contains the user permissions,
operation success [ Symlink Directory ]
SUCCESS: ACL_USER entry contains the user permissions,
but ACL_MASK are set ___ ,
operation success [ Physical Directory ]
SUCCESS: ACL_USER entry contains the user permissions,
but ACL_MASK are set ___ ,
operation success [ Symlink Directory ]
SUCCESS: ACL_GROUP entry contains the group permissions,
option success [ Physical Directory ]
SUCCESS: ACL_GROUP entry contains the group permissions,
option success [ Symlink Directory ]
SUCCESS: ACL_GROUP entry already contains the group permissions
and ACL_MASK entry are set ---,
option success [ Physical Directory ]
SUCCESS: ACL_GROUP entry already contains the group permissions
and ACL_MASK entry are set ---,
option success [ Symlink Directory ]
SUCCESS: ACL_GROUP_OBJ entry contains the group owner permissions,
option success [ Physical Directory ]
SUCCESS: ACL_GROUP_OBJ entry contains the group owner permissions,
option success [ Symlink Directory ]
SUCCESS: ACL_GROUP_OBJ entry already contains the group owner permissions
and ACL_MASK entry are set ---,
option success [ Physical Directory ]
SUCCESS: ACL_GROUP_OBJ entry already contains the group owner permissions
and ACL_MASK entry are set ---,
option success [ Symlink Directory ]
SUCCESS: ACL_OTHER entry contains the user permissions,
operation success [ Physical Directory ]
SUCCESS: ACL_OTHER entry contains the user permissions,
operation success [ Symlink Directory ]
SUCCESS: [ touch ] ACL_OTHER do not strick by ACL_MASK [ Physical Directory ]
SUCCESS: [ touch ] ACL_OTHER do not strick by ACL_MASK [ Symlink Directory ]
SUCCESS: With default ACLs set , new file permission set correct.
SUCCESS: With default ACLs set , new file permission set correct.
SUCCESS: With default ACLs set , new file permission set correct.
SUCCESS: Chmod with ACL_USER_OBJ ACL_GROUP_OBJ and ACL_OTHER are correct
SUCCESS: Chown correct
SUCCESS: ACLs backup and restore are correct
End ACLs Test
Now begin Extend Attribute Test
Attach name:value pair to object dir
Attribute "attrname1" set to a 10 byte value for shared/team2:
attrvalue1
Attach name:value pair to object file
Attribute "attrname2" set to a 10 byte value for shared/team2/file1:
attrvalue2
Attach name:value pair to object symlink file
attr_set: Operation not permitted
Could not set "attrname3" for shared/team2/symlinkfile1
INFO: Can't attach name:value pair to object symlink file
shared/team2:
total 4
-rw-rw-r-- 1 tacluser2 tacluser2 0 Mar 29 08:39 file1
lrwxrwxrwx 1 tacluser2 tacluser2 5 Mar 29 08:39 symlinkfile1 -> file1
get extended attributes of filesystem objects
Dump the values
# file: shared/team2
user.attrname1="attrvalue1"
Recursively dump the values
getfattr: Removing leading '/' from absolute path names
# file: mnt/pvfs2/testdir/tacl/shared/team2
user.attrname1="attrvalue1"
# file: mnt/pvfs2/testdir/tacl/shared/team2/file1
user.attrname2="attrvalue2"
# file: mnt/pvfs2/testdir/tacl/shared/team2/symlinkfile1
user.attrname2="attrvalue2"
Do not follow symlinks.
but extended user attributes are disallowed for symbolic links
Logical walk, follow symbolic links
# file: shared/team2/file1
user.attrname2
# file: shared/team2/symlinkfile1
user.attrname2
Physical walk, skip all symbolic links
# file: shared/team2/file1
user.attrname2
attr -g to search the named object
Attribute "attrname1" had a 10 byte value for shared/team2:
attrvalue1
attr -r to remove the named object
SUCCESS: EAs backup and restore are correct
End EAs Test
_______________________________________________
Pvfs2-developers mailing list
[email protected]
http://www.beowulf-underground.org/mailman/listinfo/pvfs2-developers
