Re: [Pvfs2-developers] ACL errors using LTP tests

Phil Carns Thu, 24 Aug 2006 06:56:06 -0700

Hmm. It looks like there must be a lot of discrepancy between differentkernel versions and different acl tools. I tried running a few tests onsome 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 thistest.

I hope that these differences are just semantic gray areas, or maybedifferences in how the acls are displayed that don't really affectbehavior. It is unsettling that the recursive dumps of acl informationon pvfs2 and ext3 don't match on RHEL4, though, because that might beimportant for archiving or backup purposes.

I'll continue looking at this to try to get a better idea of why thisscript 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@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 ]