[Pvfs2-developers] ACL errors using LTP tests

[Rob Ross]

In the mean time let's quit working on PVFS ACLs; seems like we're close 
enough that any remaining issues are lost in the noise of kernel variance.

Rob

Phil Carns wrote:
> 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--
>>
> 
> _______________________________________________
> Pvfs2-developers mailing list
> Pvfs2-developers at beowulf-underground.org
> http://www.beowulf-underground.org/mailman/listinfo/pvfs2-developers
>