[Pvfs2-developers] ACL errors using LTP tests
Phil Carns
pcarns at wastedcycles.org
Thu Aug 24 10:58:41 EDT 2006
Hmm. It looks like there must be a lot of discrepancy between different
kernel versions and different acl tools. I tried running a few tests on
some gentoo boxes here (after a minor change to the script; gentoo's
"adduser" doesn't create a home directory):
2.6.15.4 stock kernel, acl package version 2.2.32:
-------------------
I get these same errors out of both ext3 and pvfs2:
FAILED: [ touch ] ACL_GROUP entry already contains the group permissions,
FAILED: [ touch ] ACL_GROUP entry already contains the group permissions,
FAILED: ACL_OTHER do not strick by ACL_MASK [ Physical Directory ]
FAILED: ACL_OTHER do not strick by ACL_MASK [ Symlink Directory ]
FAILED: With default ACLs set , new file permission set not correct
FAILED: With default ACLs set , new file permission set not correct
FAILED: Chmod with ACL_USER_OBJ ACL_GROUP_OBJ and ACL_OTHER are not correct
FAILED: Chown are not correct
2.6.13 stock kernel, acl package version 2.2.34:
--------------------
I get these errors on ext3 (didn't try pvfs2):
FAILED: ACL_USER entry contains the user permissions,
FAILED: ACL_USER entry contains the user permissions,
FAILED: [ touch ] ACL_GROUP entry already contains the group permissions,
FAILED: [ touch ] ACL_GROUP entry already contains the group permissions,
FAILED: [ touch ] ACL_GROUP_OBJ entry contains the group owner permissions
FAILED: [ touch ] ACL_GROUP_OBJ entry contains the group owner permissions
FAILED: With default ACLs set , new file permission set not correct
FAILED: With default ACLs set , new file permission set not correct
FAILED: Chmod with ACL_USER_OBJ ACL_GROUP_OBJ and ACL_OTHER are not correct
FAILED: Chown are not correct
That's disappointing :( That makes 4 different configurations (FC5,
RHEL4, and two Gentoo examples) that all disagree on the results of this
test.
I hope that these differences are just semantic gray areas, or maybe
differences in how the acls are displayed that don't really affect
behavior. It is unsettling that the recursive dumps of acl information
on pvfs2 and ext3 don't match on RHEL4, though, because that might be
important for archiving or backup purposes.
I'll continue looking at this to try to get a better idea of why this
script acts so differently on different machines.
-Phil
Murali Vilayannur wrote:
> Phil,
> Here is my output from my FC5 box running a modified 2.6.16 kernel
> (provided by FC5). None of those modifications would affect the acl and
> xattr tests though.
> Does not look like I am seeing any of the errors that you are describing.
> All the outputs look identical to me ...
>
> Some of these look like userspace bugs (attr and acl rpm's) and I guess
> some may be kernel bugs fixed in newer kernels.. Cant say for sure.
> Let me know if you find out anything..
> Thanks,
> Murali
>
> On Wed, 23 Aug 2006, Phil Carns wrote:
>
>
>>I am fairly sure that I was running this with the current CVS head. We
>>originally saw these latest problems in our local tree after a vendor
>>merge, but I switched to the HEAD version from Clemson this afternoon to
>>double check that we didn't introduce anything on our end (that's when I
>>saw the memory problems from the encoder that Sam has since fixed).
>>
>>I will try repeating this on a system with a stock kernel.org kernel to
>>see if there is anything odd about these rhel4 kernels, but for some
>>reason I am having some problem (not pvfs2 related) getting the test
>>script to run on my normal development box.
>>
>>-Phil
>>
>>Murali Vilayannur wrote:
>>
>>>Hi Phil,
>>>Drat.. this ACL thing is really proving to be annoying :)
>>>I dont see any errors on FC5 (2.6.16 kernels) as far as I can tell..
>>>
>>>
>>>
>>>>problems, though. We are running tests on a redhat 2.6.9-34.0.2.ELsmp
>>>>kernel.
>>>>
>>>>There is still one failure listed on PVFS2:
>>>>
>>>> Do not follow symlinks.
>>>> but extended user attributes are disallowed for symbolic links
>>>> getfattr: shared/team2/symlinkfile1: Operation not supported
>>>> FAILED: getfattr: Do not follow symlinks.
>>>
>>>
>>>Was this with the cvs head? I thought I updated the error messages..
>>>
>>>
>>>
>>>>Towards the end of the test, there are also some extra error messages
>>>>generated, though these aren't registered as a "FAILED" by the test script:
>>>>
>>>> attr -r to remove the named object
>>>> getfattr: shared/team1/symlinkfile1: Operation not supported
>>>> getfattr: shared/team2/symlinkfile1: Operation not supported
>>>> getfattr: shared/team1/symlinkfile1: Operation not supported
>>>> getfattr: shared/team2/symlinkfile1: Operation not supported
>>>
>>>
>>>Again, I thought I fixed all these errors in HEAD.. can you check if you
>>>are running the latest version?
>>>
>>>
>>>
>>>>There is one other difference between ext3 and pvfs2, though it isn't
>>>>clear if this is an error or not. At one point in the test, ext3 shows
>>>>this output:
>>>>
>>>> SUCCESS: Chown correct
>>>> setfacl: shared/symlinkdir1: Only directories can have default ACLs
>>>>While PVFS2 only shows this:
>>>>
>>>> SUCCESS: Chown correct
>>>
>>>
>>>Hmm..setfacl program prints this error message for ext3 and not for
>>>pvfs2! wow. So this looks like a case where pvfs2 might be doing the right
>>>thing and not ext3 :) I will dig up some more..
>>>
>>>
>>>
>>>>David also pointed out another interesting piece of information. There
>>>>is a line in the test script that runs "getfacl -RL shared > tmp1".
>>>>This is recursively dumping acls from one of the test directory. If you
>>>>compare the output of this command in PVFS2 and EXT3 (by saving that
>>>>tmp1 file) there are some significant differences, aside from the
>>>>expected ordering and path differences. This is one example (some
>>>>objects, particularly related to symlinks, don't show up on pvfs2),
>>>>though there may be some other differences:
>>>>
>>>> $ grep symlinkdir1 /tmp/tmp1.ext3
>>>> # file: shared/symlinkdir1
>>>> # file: shared/symlinkdir1/symlinkfile1
>>>> # file: shared/symlinkdir1/newfile1
>>>> # file: shared/symlinkdir1/file1
>>>> # file: shared/symlinkdir1/newfile3
>>>> # file: shared/symlinkdir1/newfile2
>>>> $ grep symlinkdir1 /tmp/tmp1.pvfs2
>>>> $
>>>>
>>>>Do you have any of these same differences on your platform?
>>>
>>>
>>>Hmm.. Nope. getfacl should follow symbolic links with those arguments..
>>>sigh. let me re-run them and see if I see similar behavior.
>>>something with the user-space tools is buggy?
>>>
>>>
>>>
>>>>Oh, and one other thing. The acl code in the kernel is printing a lot
>>>>of information into dmesg right now. After running these tests there
>>>>are many duplicates of each of the following messages in the kernel logs:
>>>>
>>>> pvfs2_acl_chmod: get acl (access) failed with 0
>>>> pvfs2_get_acl failed due to no acls!
>>>
>>>
>>>Please feel free to remove them from HEAD. I was so defensive when I was
>>>debugging these tests that I forgot to disable them when I checked the
>>>changes in.
>>>
>>>I will let you know over the course of the week if I find out anything
>>>thanks,
>>>Murali
>>>
>>>
>>> >
>>>
>>>>thanks again,
>>>>-Phil
>>>>
>>>>Murali Vilayannur wrote:
>>>>
>>>>
>>>>>David,
>>>>>
>>>>>I think I have fixed the last of the failed tests with LTP and ACLs.
>>>>>(replaced EOPNOTSUPP with EACCES). I have tested this only on FC5.
>>>>>Hopefully, things work on your platform now. It is possible that the
>>>>>differences we see could be because of kernel versions or something?
>>>>>Please let me know if anything else fails,
>>>>>Thanks,
>>>>>Murali
>>>>>_______________________________________________
>>>>>Pvfs2-developers mailing list
>>>>>Pvfs2-developers at beowulf-underground.org
>>>>>http://www.beowulf-underground.org/mailman/listinfo/pvfs2-developers
>>>>
>>>>
>>
>
>
> ------------------------------------------------------------------------
>
>
> 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 1
> -rw-rw-r-- 1 tacluser2 tacluser2 0 Aug 23 18:33 file1
> lrwxrwxrwx 1 tacluser2 tacluser2 5 Aug 23 18:33 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: tmp/ext3/disk/tacl/shared/team2
> user.attrname1="attrvalue1"
>
> # file: tmp/ext3/disk/tacl/shared/team2/file1
> user.attrname2="attrvalue2"
>
> # file: tmp/ext3/disk/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
>
>
> ------------------------------------------------------------------------
>
> # file: shared
> # owner: root
> # group: root
> user::rwx
> group::rwx
> other::rwx
>
> # file: shared/team1
> # owner: tacluser1
> # group: tacluser1
> user::rwx
> user:tacluser3:rwx #effective:---
> group::rwx #effective:---
> group:tacluser2:rwx #effective:---
> mask::---
> other::rwx
> default:user::rwx
> default:user:tacluser3:rw-
> default:group::rwx
> default:group:tacluser3:rw-
> default:mask::rwx
> default:other::rwx
>
> # file: shared/team1/file1
> # owner: tacluser1
> # group: tacluser1
> user::rw-
> group::rw-
> other::r--
>
> # file: shared/team1/symlinkfile1
> # owner: tacluser1
> # group: tacluser1
> user::rw-
> group::rw-
> other::r--
>
> # file: shared/team1/newfile1
> # owner: tacluser1
> # group: tacluser1
> user::r--
> group::r--
> other::r--
>
> # file: shared/team1/newfile2
> # owner: tacluser2
> # group: tacluser2
> user::r--
> user:tacluser3:rw-
> group::r--
> group:tacluser3:rw-
> mask::rw-
> other::r--
>
> # file: shared/team1/newfile3
> # owner: tacluser3
> # group: tacluser3
> user::rwx
> user:tacluser3:rw-
> group::rwx
> group:tacluser3:rw-
> mask::rwx
> other::rwx
>
> # file: shared/team2
> # owner: tacluser2
> # group: tacluser2
> user::rwx
> group::rwx
> other::r-x
>
> # file: shared/team2/file1
> # owner: tacluser2
> # group: tacluser2
> user::rw-
> group::rw-
> other::r--
>
> # file: shared/team2/symlinkfile1
> # owner: tacluser2
> # group: tacluser2
> user::rw-
> group::rw-
> other::r--
>
>
>
> ------------------------------------------------------------------------
>
>
> 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 Aug 23 18:41 file1
> lrwxrwxrwx 1 tacluser2 tacluser2 5 Aug 23 18:41 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/acl/tacl/shared/team2
> user.attrname1="attrvalue1"
>
> # file: mnt/pvfs2/acl/tacl/shared/team2/file1
> user.attrname2="attrvalue2"
>
> # file: mnt/pvfs2/acl/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
>
>
> ------------------------------------------------------------------------
>
> # file: shared
> # owner: root
> # group: root
> user::rwx
> group::rwx
> other::rwx
>
> # file: shared/team1
> # owner: tacluser1
> # group: tacluser1
> user::rwx
> user:tacluser3:rwx #effective:---
> group::rwx #effective:---
> group:tacluser2:rwx #effective:---
> mask::---
> other::rwx
> default:user::rwx
> default:user:tacluser3:rw-
> default:group::rwx
> default:group:tacluser3:rw-
> default:mask::rwx
> default:other::rwx
>
> # file: shared/team1/file1
> # owner: tacluser1
> # group: tacluser1
> user::rw-
> group::rw-
> other::r--
>
> # file: shared/team1/newfile1
> # owner: tacluser1
> # group: tacluser1
> user::r--
> group::r--
> other::r--
>
> # file: shared/team1/newfile2
> # owner: tacluser2
> # group: tacluser2
> user::r--
> user:tacluser3:rw-
> group::r--
> group:tacluser3:rw-
> mask::rw-
> other::r--
>
> # file: shared/team1/newfile3
> # owner: tacluser3
> # group: tacluser3
> user::rwx
> user:tacluser3:rw-
> group::rwx
> group:tacluser3:rw-
> mask::rwx
> other::rwx
>
> # file: shared/team1/symlinkfile1
> # owner: tacluser1
> # group: tacluser1
> user::rw-
> group::rw-
> other::r--
>
> # file: shared/team2
> # owner: tacluser2
> # group: tacluser2
> user::rwx
> group::rwx
> other::r-x
>
> # file: shared/team2/file1
> # owner: tacluser2
> # group: tacluser2
> user::rw-
> group::rw-
> other::r--
>
> # file: shared/team2/symlinkfile1
> # owner: tacluser2
> # group: tacluser2
> user::rw-
> group::rw-
> other::r--
>
More information about the Pvfs2-developers
mailing list