Uploaded image for project: 'Lustre'
  1. Lustre
  2. LU-5434

Invalid system.posix_acl_access breaks permissions enforcement

Details

    • Bug
    • Resolution: Fixed
    • Minor
    • Lustre 2.7.0, Lustre 2.5.4
    • Lustre 2.6.0, Lustre 2.7.0, Lustre 2.5.3
    • None
    • lustre-2.4.2-14chaos
    • 3
    • 15135

    Description

      With a ZFS MDT it is possible to create files and directories with invalid "empty" ACLs. We have observed that this can lead to permission denied errors when access should be granted based on group membership. More specifically, if a directory has an invalid system.posix_acl_access xattr, a user may be unexpectedly denied access to it. If the root user populates the local cache by listing the directory, the non-root user is no longer denied access, at least until caches are dropped.

      The console session below demonstrates the behavior. First we create an invalid default ACL using setfattr. Then we create a subdirectory which inherits the invalid ACL in system.posix_acl_access. A user then gets permission denied for the new subdirectory until root lists it.

      # hype356 /p/lcratery/bass6 > chown bass6:fstest .
      # hype356 /p/lcratery/bass6 > chmod 750 .
      # hype356 /p/lcratery/bass6 > setfattr -n system.posix_acl_default -v '\002\000\000\000' .
      # hype356 /p/lcratery/bass6 > mkdir t
      # hype356 /p/lcratery/bass6 > getfattr -m. -d t > /dev/null
      t: system.posix_acl_access: No such attribute
      # hype356 /p/lcratery/bass6 > chown bass6:fstest t
      # hype356 /p/lcratery/bass6 > chmod 750 t
      # hype356 /p/lcratery/bass6 > touch t/f
       
      # hype356 /p/lcratery/bass6 >
      # hype356 /p/lcratery/bass6 > cd t
      # hype356 /p/lcratery/bass6/t > su behlendo -c "/bin/ls -l `pwd`"
      /bin/ls: cannot open directory /p/lcratery/bass6/t: Permission denied
      # hype356 /p/lcratery/bass6/t > ls -al
      total 12
      drwxr-x--- 2 bass6 fstest 5632 Jul 30 19:28 .
      drwxr-x--- 3 bass6 fstest 5632 Jul 30 19:28 ..
      -rw-rw-rw- 1 root  root      0 Jul 30 19:29 f
      # hype356 /p/lcratery/bass6/t > su behlendo -c "/bin/ls -l `pwd`"
      total 1
      -rw-rw-rw- 1 root root 0 Jul 30 19:29 f
      # hype356 /p/lcratery/bass6 > groups behlendo
      behlendo : behlendo bgldev fstest lcstaff linuxdev
      

      Attachments

        Issue Links

          Activity

            [LU-5434] Invalid system.posix_acl_access breaks permissions enforcement
            pjones Peter Jones added a comment -

            2.7!

            pjones Peter Jones added a comment - 2.7!
            emoly.liu Emoly Liu added a comment -

            Patch landed to 2.6.

            emoly.liu Emoly Liu added a comment - Patch landed to 2.6.
            emoly.liu Emoly Liu added a comment -

            Thanks for your patch.

            emoly.liu Emoly Liu added a comment - Thanks for your patch.
            nedbass Ned Bass (Inactive) added a comment - Patch for master: http://review.whamcloud.com/#/c/11300

            The invalid ACLs can be created using cp. This is why we are noticing the problem on our production systems. Our users run into this after using cp and tar. Note below that the final getfattr command prints an error regarding system.posix_acl_access. This is because that name shows up in the list returned by listxattr(), but getxattr() returns ENODATA for it. The zdb command on the MDT shows that it has the same invalid value as the parent's posix_acl_default.

            # hype356 /p/lcratery/bass6 > mkdir d1
            # hype356 /p/lcratery/bass6 > getfattr -n system.posix_acl_default d1
            # file: d1
            system.posix_acl_default
            # hype356 /p/lcratery/bass6 > cp -rp d1 d2
            # hype356 /p/lcratery/bass6 > getfattr -n system.posix_acl_default d2
            # file: d2
            system.posix_acl_default=0sAgAAAA==
            # hype356 /p/lcratery/bass6 > mkdir d2/s2
            # hype356 /p/lcratery/bass6 > getfattr -m. -d  d2/s2
            d2/s2: system.posix_acl_access: No such attribute
            # file: d2/s2
            system.posix_acl_default=0sAgAAAA==
            trusted.link=0s3/HqEQEAAAAsAAAAAAAAAAAAAAAAAAAAABQAAAACAABiQwAAAHAAAAAAczI=
            trusted.lma=0sAAAAAAAAAABDYgAAAgAAAHEAAAAAAAAA
            trusted.version=0sDAaWCRAAAAA=
            
            nedbass Ned Bass (Inactive) added a comment - The invalid ACLs can be created using cp . This is why we are noticing the problem on our production systems. Our users run into this after using cp and tar . Note below that the final getfattr command prints an error regarding system.posix_acl_access . This is because that name shows up in the list returned by listxattr() , but getxattr() returns ENODATA for it. The zdb command on the MDT shows that it has the same invalid value as the parent's posix_acl_default . # hype356 /p/lcratery/bass6 > mkdir d1 # hype356 /p/lcratery/bass6 > getfattr -n system.posix_acl_default d1 # file: d1 system.posix_acl_default # hype356 /p/lcratery/bass6 > cp -rp d1 d2 # hype356 /p/lcratery/bass6 > getfattr -n system.posix_acl_default d2 # file: d2 system.posix_acl_default=0sAgAAAA== # hype356 /p/lcratery/bass6 > mkdir d2/s2 # hype356 /p/lcratery/bass6 > getfattr -m. -d d2/s2 d2/s2: system.posix_acl_access: No such attribute # file: d2/s2 system.posix_acl_default=0sAgAAAA== trusted.link=0s3/HqEQEAAAAsAAAAAAAAAAAAAAAAAAAAABQAAAACAABiQwAAAHAAAAAAczI= trusted.lma=0sAAAAAAAAAABDYgAAAgAAAHEAAAAAAAAA trusted.version=0sDAaWCRAAAAA=
            pjones Peter Jones added a comment -

            Emoly

            Could you please assist with this one?

            Thanks

            Peter

            pjones Peter Jones added a comment - Emoly Could you please assist with this one? Thanks Peter

            People

              emoly.liu Emoly Liu
              nedbass Ned Bass (Inactive)
              Votes:
              0 Vote for this issue
              Watchers:
              4 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved: