ACL not honored by mv and tar












3














I'm trying to setup an area on my ext4 filesystem (on Debian Jessie), where all "staff" group members can read and write existing and newly created files.



The filesystem is mounted with acl option:



$ more /etc/fstab | grep acl
UUID=f47c5337-a6e1-4554-b8c0-e05c761ec835 / ext4 noatime,errors=remount-ro,acl 0 1


I've created a few bash script in order to set ACL's on a directoty and test it against various scenarios.



The first one (createtestdir.sh) creates a test directory with a few files and dir inside:



#!/bin/bash

if [ $# != 1 ]; then
echo "usage: $0 /path/to/new/directory"
exit
fi

if [ ! -d "$1" ] && [ ! -f "$1" ] && [ ! -L "$1" ]
then
mkdir $1
mkdir $1/dir
touch $1/file
touch $1/dir/file
echo "Directory $1 created"
else
echo "$1 already exist"
fi


The second one (setacl.sh) set permissions and ACL's on the specified directory, maybe problems arise here:



#!/bin/bash

if [ $# != 1 ]; then
echo "usage: $0 /path/to/directory"
exit
fi

if [ -d "$1" ]; then
chgrp -R staff $1
chmod g+rwxs $1
setfacl -dm group:staff:rwx $1
/usr/bin/find $1 -type d -exec chmod g+rwxs {} +
/usr/bin/find $1 -type d -exec setfacl -dm group:staff:rwx {} +
/usr/bin/find $1 -type f -exec chmod g+rw {} +
/usr/bin/find $1 -type f -exec setfacl -m group:staff:rw {} +

echo "Permission changed"
else
echo "Directory $1 does not exist"
fi


Finally the third script (acltest.sh) tests ACL's behavior creating file and directories, moving, copying and untarring and archive:



#!/bin/bash

if [ $# != 1 ]; then
echo "usage: $0 /path/to/directory"
exit
fi

if [ -d "$1" ]
then
#testing acl
mkdir $1/test_dir
touch $1/test_dir/file
touch $1/test_file
# testing mv
touch $1/file_from_internal
touch file_from_external
ls -l file_from_external
mv file_from_external $1
# testing tar && cp
mkdir test_tar
touch test_tar/file
tar cjf test.tar.bz2 test_tar
cp test.tar.bz2 $1
ls -ld test_tar
ls -l test.tar.bz2
rm -rf test_tar
rm test.tar.bz2
cd $1
tar xjf test.tar.bz2
echo "Test on $1 completed"
else
echo "$1 already exist"
fi


Executing the scripts the scripts in the correct order give you the following output:



$ ./createtestdir.sh Acl
Directory Acl created
$ ./setacl.sh Acl/
Permission changed
$ ./acltest.sh Acl/
-rw-r--r-- 1 gabo gabo 0 feb 24 11:58 file_from_external
drwxr-xr-x 2 gabo gabo 4096 feb 24 11:24 test_tar
-rw-r--r-- 1 gabo gabo 146 feb 24 11:24 test.tar.bz2
Test on Acl/ completed


I printed out the permissions of the directory and the file that are respectively untarred and copyed inside the Acl test directory, so they can be compared against the respective files inside the Acl test directory.



As you can see with ls, pemissions and ACL's are not the expected (by me, of course :)



$ ls -l Acl/
totale 16
drwxrwsr-x+ 2 gabo staff 4096 feb 24 11:24 dir
-rw-rw-r--+ 1 gabo staff 0 feb 24 11:24 file
-rw-r--r-- 1 gabo gabo 0 feb 24 11:24 file_from_external
-rw-rw-r--+ 1 gabo staff 0 feb 24 11:24 file_from_internal
drwxrwsr-x+ 2 gabo staff 4096 feb 24 11:24 test_dir
-rw-rw-r--+ 1 gabo staff 0 feb 24 11:24 test_file
drwxr-sr-x+ 2 gabo staff 4096 feb 24 11:24 test_tar
-rw-r--r--+ 1 gabo staff 146 feb 24 11:24 test.tar.bz2


file_from_internal is ok. It was created inside the directory and has right permissions and ACL.



file_from_external ins't ok. It was moved from the parent directory, it carries the old permissions, and it hasn't the ACL. It seems that mv command doesn't work with ACL.



test.tar.bz2 is strange. It was copied from the parent directory, it carries the old permissions, and it implements wrong ACL (file is not writeable by staff group):



$ getfacl Acl/test.tar.bz2 
# file: Acl/test.tar.bz2
# owner: gabo
# group: staff
user::rw-
group::rwx #effective:r--
group:staff:rwx #effective:r--
mask::r--
other::r--


It seems that cp also does't work with ACL



test_tar directory also doesn't have group write permission, but it inherits ACL default behavior :/



$ getfacl Acl/test_tar
# file: Acl/test_tar
# owner: gabo
# group: staff
# flags: -s-
user::rwx
group::rwx #effective:r-x
group:staff:rwx #effective:r-x
mask::r-x
other::r-x
default:user::rwx
default:group::rwx
default:group:staff:rwx
default:mask::rwx
default:other::r-x


If I try to create a file inside test_tar using a different user (member of staff), I get a permission denied error.



What's wrong in my setacl.sh script? Maybe there's some bug/gotcha/behavior that I'm not aware of?



I would like to provide a replicable test suite in order to check it over different environments without typing a lot of shell commands.










share|improve this question





























    3














    I'm trying to setup an area on my ext4 filesystem (on Debian Jessie), where all "staff" group members can read and write existing and newly created files.



    The filesystem is mounted with acl option:



    $ more /etc/fstab | grep acl
    UUID=f47c5337-a6e1-4554-b8c0-e05c761ec835 / ext4 noatime,errors=remount-ro,acl 0 1


    I've created a few bash script in order to set ACL's on a directoty and test it against various scenarios.



    The first one (createtestdir.sh) creates a test directory with a few files and dir inside:



    #!/bin/bash

    if [ $# != 1 ]; then
    echo "usage: $0 /path/to/new/directory"
    exit
    fi

    if [ ! -d "$1" ] && [ ! -f "$1" ] && [ ! -L "$1" ]
    then
    mkdir $1
    mkdir $1/dir
    touch $1/file
    touch $1/dir/file
    echo "Directory $1 created"
    else
    echo "$1 already exist"
    fi


    The second one (setacl.sh) set permissions and ACL's on the specified directory, maybe problems arise here:



    #!/bin/bash

    if [ $# != 1 ]; then
    echo "usage: $0 /path/to/directory"
    exit
    fi

    if [ -d "$1" ]; then
    chgrp -R staff $1
    chmod g+rwxs $1
    setfacl -dm group:staff:rwx $1
    /usr/bin/find $1 -type d -exec chmod g+rwxs {} +
    /usr/bin/find $1 -type d -exec setfacl -dm group:staff:rwx {} +
    /usr/bin/find $1 -type f -exec chmod g+rw {} +
    /usr/bin/find $1 -type f -exec setfacl -m group:staff:rw {} +

    echo "Permission changed"
    else
    echo "Directory $1 does not exist"
    fi


    Finally the third script (acltest.sh) tests ACL's behavior creating file and directories, moving, copying and untarring and archive:



    #!/bin/bash

    if [ $# != 1 ]; then
    echo "usage: $0 /path/to/directory"
    exit
    fi

    if [ -d "$1" ]
    then
    #testing acl
    mkdir $1/test_dir
    touch $1/test_dir/file
    touch $1/test_file
    # testing mv
    touch $1/file_from_internal
    touch file_from_external
    ls -l file_from_external
    mv file_from_external $1
    # testing tar && cp
    mkdir test_tar
    touch test_tar/file
    tar cjf test.tar.bz2 test_tar
    cp test.tar.bz2 $1
    ls -ld test_tar
    ls -l test.tar.bz2
    rm -rf test_tar
    rm test.tar.bz2
    cd $1
    tar xjf test.tar.bz2
    echo "Test on $1 completed"
    else
    echo "$1 already exist"
    fi


    Executing the scripts the scripts in the correct order give you the following output:



    $ ./createtestdir.sh Acl
    Directory Acl created
    $ ./setacl.sh Acl/
    Permission changed
    $ ./acltest.sh Acl/
    -rw-r--r-- 1 gabo gabo 0 feb 24 11:58 file_from_external
    drwxr-xr-x 2 gabo gabo 4096 feb 24 11:24 test_tar
    -rw-r--r-- 1 gabo gabo 146 feb 24 11:24 test.tar.bz2
    Test on Acl/ completed


    I printed out the permissions of the directory and the file that are respectively untarred and copyed inside the Acl test directory, so they can be compared against the respective files inside the Acl test directory.



    As you can see with ls, pemissions and ACL's are not the expected (by me, of course :)



    $ ls -l Acl/
    totale 16
    drwxrwsr-x+ 2 gabo staff 4096 feb 24 11:24 dir
    -rw-rw-r--+ 1 gabo staff 0 feb 24 11:24 file
    -rw-r--r-- 1 gabo gabo 0 feb 24 11:24 file_from_external
    -rw-rw-r--+ 1 gabo staff 0 feb 24 11:24 file_from_internal
    drwxrwsr-x+ 2 gabo staff 4096 feb 24 11:24 test_dir
    -rw-rw-r--+ 1 gabo staff 0 feb 24 11:24 test_file
    drwxr-sr-x+ 2 gabo staff 4096 feb 24 11:24 test_tar
    -rw-r--r--+ 1 gabo staff 146 feb 24 11:24 test.tar.bz2


    file_from_internal is ok. It was created inside the directory and has right permissions and ACL.



    file_from_external ins't ok. It was moved from the parent directory, it carries the old permissions, and it hasn't the ACL. It seems that mv command doesn't work with ACL.



    test.tar.bz2 is strange. It was copied from the parent directory, it carries the old permissions, and it implements wrong ACL (file is not writeable by staff group):



    $ getfacl Acl/test.tar.bz2 
    # file: Acl/test.tar.bz2
    # owner: gabo
    # group: staff
    user::rw-
    group::rwx #effective:r--
    group:staff:rwx #effective:r--
    mask::r--
    other::r--


    It seems that cp also does't work with ACL



    test_tar directory also doesn't have group write permission, but it inherits ACL default behavior :/



    $ getfacl Acl/test_tar
    # file: Acl/test_tar
    # owner: gabo
    # group: staff
    # flags: -s-
    user::rwx
    group::rwx #effective:r-x
    group:staff:rwx #effective:r-x
    mask::r-x
    other::r-x
    default:user::rwx
    default:group::rwx
    default:group:staff:rwx
    default:mask::rwx
    default:other::r-x


    If I try to create a file inside test_tar using a different user (member of staff), I get a permission denied error.



    What's wrong in my setacl.sh script? Maybe there's some bug/gotcha/behavior that I'm not aware of?



    I would like to provide a replicable test suite in order to check it over different environments without typing a lot of shell commands.










    share|improve this question



























      3












      3








      3


      1





      I'm trying to setup an area on my ext4 filesystem (on Debian Jessie), where all "staff" group members can read and write existing and newly created files.



      The filesystem is mounted with acl option:



      $ more /etc/fstab | grep acl
      UUID=f47c5337-a6e1-4554-b8c0-e05c761ec835 / ext4 noatime,errors=remount-ro,acl 0 1


      I've created a few bash script in order to set ACL's on a directoty and test it against various scenarios.



      The first one (createtestdir.sh) creates a test directory with a few files and dir inside:



      #!/bin/bash

      if [ $# != 1 ]; then
      echo "usage: $0 /path/to/new/directory"
      exit
      fi

      if [ ! -d "$1" ] && [ ! -f "$1" ] && [ ! -L "$1" ]
      then
      mkdir $1
      mkdir $1/dir
      touch $1/file
      touch $1/dir/file
      echo "Directory $1 created"
      else
      echo "$1 already exist"
      fi


      The second one (setacl.sh) set permissions and ACL's on the specified directory, maybe problems arise here:



      #!/bin/bash

      if [ $# != 1 ]; then
      echo "usage: $0 /path/to/directory"
      exit
      fi

      if [ -d "$1" ]; then
      chgrp -R staff $1
      chmod g+rwxs $1
      setfacl -dm group:staff:rwx $1
      /usr/bin/find $1 -type d -exec chmod g+rwxs {} +
      /usr/bin/find $1 -type d -exec setfacl -dm group:staff:rwx {} +
      /usr/bin/find $1 -type f -exec chmod g+rw {} +
      /usr/bin/find $1 -type f -exec setfacl -m group:staff:rw {} +

      echo "Permission changed"
      else
      echo "Directory $1 does not exist"
      fi


      Finally the third script (acltest.sh) tests ACL's behavior creating file and directories, moving, copying and untarring and archive:



      #!/bin/bash

      if [ $# != 1 ]; then
      echo "usage: $0 /path/to/directory"
      exit
      fi

      if [ -d "$1" ]
      then
      #testing acl
      mkdir $1/test_dir
      touch $1/test_dir/file
      touch $1/test_file
      # testing mv
      touch $1/file_from_internal
      touch file_from_external
      ls -l file_from_external
      mv file_from_external $1
      # testing tar && cp
      mkdir test_tar
      touch test_tar/file
      tar cjf test.tar.bz2 test_tar
      cp test.tar.bz2 $1
      ls -ld test_tar
      ls -l test.tar.bz2
      rm -rf test_tar
      rm test.tar.bz2
      cd $1
      tar xjf test.tar.bz2
      echo "Test on $1 completed"
      else
      echo "$1 already exist"
      fi


      Executing the scripts the scripts in the correct order give you the following output:



      $ ./createtestdir.sh Acl
      Directory Acl created
      $ ./setacl.sh Acl/
      Permission changed
      $ ./acltest.sh Acl/
      -rw-r--r-- 1 gabo gabo 0 feb 24 11:58 file_from_external
      drwxr-xr-x 2 gabo gabo 4096 feb 24 11:24 test_tar
      -rw-r--r-- 1 gabo gabo 146 feb 24 11:24 test.tar.bz2
      Test on Acl/ completed


      I printed out the permissions of the directory and the file that are respectively untarred and copyed inside the Acl test directory, so they can be compared against the respective files inside the Acl test directory.



      As you can see with ls, pemissions and ACL's are not the expected (by me, of course :)



      $ ls -l Acl/
      totale 16
      drwxrwsr-x+ 2 gabo staff 4096 feb 24 11:24 dir
      -rw-rw-r--+ 1 gabo staff 0 feb 24 11:24 file
      -rw-r--r-- 1 gabo gabo 0 feb 24 11:24 file_from_external
      -rw-rw-r--+ 1 gabo staff 0 feb 24 11:24 file_from_internal
      drwxrwsr-x+ 2 gabo staff 4096 feb 24 11:24 test_dir
      -rw-rw-r--+ 1 gabo staff 0 feb 24 11:24 test_file
      drwxr-sr-x+ 2 gabo staff 4096 feb 24 11:24 test_tar
      -rw-r--r--+ 1 gabo staff 146 feb 24 11:24 test.tar.bz2


      file_from_internal is ok. It was created inside the directory and has right permissions and ACL.



      file_from_external ins't ok. It was moved from the parent directory, it carries the old permissions, and it hasn't the ACL. It seems that mv command doesn't work with ACL.



      test.tar.bz2 is strange. It was copied from the parent directory, it carries the old permissions, and it implements wrong ACL (file is not writeable by staff group):



      $ getfacl Acl/test.tar.bz2 
      # file: Acl/test.tar.bz2
      # owner: gabo
      # group: staff
      user::rw-
      group::rwx #effective:r--
      group:staff:rwx #effective:r--
      mask::r--
      other::r--


      It seems that cp also does't work with ACL



      test_tar directory also doesn't have group write permission, but it inherits ACL default behavior :/



      $ getfacl Acl/test_tar
      # file: Acl/test_tar
      # owner: gabo
      # group: staff
      # flags: -s-
      user::rwx
      group::rwx #effective:r-x
      group:staff:rwx #effective:r-x
      mask::r-x
      other::r-x
      default:user::rwx
      default:group::rwx
      default:group:staff:rwx
      default:mask::rwx
      default:other::r-x


      If I try to create a file inside test_tar using a different user (member of staff), I get a permission denied error.



      What's wrong in my setacl.sh script? Maybe there's some bug/gotcha/behavior that I'm not aware of?



      I would like to provide a replicable test suite in order to check it over different environments without typing a lot of shell commands.










      share|improve this question















      I'm trying to setup an area on my ext4 filesystem (on Debian Jessie), where all "staff" group members can read and write existing and newly created files.



      The filesystem is mounted with acl option:



      $ more /etc/fstab | grep acl
      UUID=f47c5337-a6e1-4554-b8c0-e05c761ec835 / ext4 noatime,errors=remount-ro,acl 0 1


      I've created a few bash script in order to set ACL's on a directoty and test it against various scenarios.



      The first one (createtestdir.sh) creates a test directory with a few files and dir inside:



      #!/bin/bash

      if [ $# != 1 ]; then
      echo "usage: $0 /path/to/new/directory"
      exit
      fi

      if [ ! -d "$1" ] && [ ! -f "$1" ] && [ ! -L "$1" ]
      then
      mkdir $1
      mkdir $1/dir
      touch $1/file
      touch $1/dir/file
      echo "Directory $1 created"
      else
      echo "$1 already exist"
      fi


      The second one (setacl.sh) set permissions and ACL's on the specified directory, maybe problems arise here:



      #!/bin/bash

      if [ $# != 1 ]; then
      echo "usage: $0 /path/to/directory"
      exit
      fi

      if [ -d "$1" ]; then
      chgrp -R staff $1
      chmod g+rwxs $1
      setfacl -dm group:staff:rwx $1
      /usr/bin/find $1 -type d -exec chmod g+rwxs {} +
      /usr/bin/find $1 -type d -exec setfacl -dm group:staff:rwx {} +
      /usr/bin/find $1 -type f -exec chmod g+rw {} +
      /usr/bin/find $1 -type f -exec setfacl -m group:staff:rw {} +

      echo "Permission changed"
      else
      echo "Directory $1 does not exist"
      fi


      Finally the third script (acltest.sh) tests ACL's behavior creating file and directories, moving, copying and untarring and archive:



      #!/bin/bash

      if [ $# != 1 ]; then
      echo "usage: $0 /path/to/directory"
      exit
      fi

      if [ -d "$1" ]
      then
      #testing acl
      mkdir $1/test_dir
      touch $1/test_dir/file
      touch $1/test_file
      # testing mv
      touch $1/file_from_internal
      touch file_from_external
      ls -l file_from_external
      mv file_from_external $1
      # testing tar && cp
      mkdir test_tar
      touch test_tar/file
      tar cjf test.tar.bz2 test_tar
      cp test.tar.bz2 $1
      ls -ld test_tar
      ls -l test.tar.bz2
      rm -rf test_tar
      rm test.tar.bz2
      cd $1
      tar xjf test.tar.bz2
      echo "Test on $1 completed"
      else
      echo "$1 already exist"
      fi


      Executing the scripts the scripts in the correct order give you the following output:



      $ ./createtestdir.sh Acl
      Directory Acl created
      $ ./setacl.sh Acl/
      Permission changed
      $ ./acltest.sh Acl/
      -rw-r--r-- 1 gabo gabo 0 feb 24 11:58 file_from_external
      drwxr-xr-x 2 gabo gabo 4096 feb 24 11:24 test_tar
      -rw-r--r-- 1 gabo gabo 146 feb 24 11:24 test.tar.bz2
      Test on Acl/ completed


      I printed out the permissions of the directory and the file that are respectively untarred and copyed inside the Acl test directory, so they can be compared against the respective files inside the Acl test directory.



      As you can see with ls, pemissions and ACL's are not the expected (by me, of course :)



      $ ls -l Acl/
      totale 16
      drwxrwsr-x+ 2 gabo staff 4096 feb 24 11:24 dir
      -rw-rw-r--+ 1 gabo staff 0 feb 24 11:24 file
      -rw-r--r-- 1 gabo gabo 0 feb 24 11:24 file_from_external
      -rw-rw-r--+ 1 gabo staff 0 feb 24 11:24 file_from_internal
      drwxrwsr-x+ 2 gabo staff 4096 feb 24 11:24 test_dir
      -rw-rw-r--+ 1 gabo staff 0 feb 24 11:24 test_file
      drwxr-sr-x+ 2 gabo staff 4096 feb 24 11:24 test_tar
      -rw-r--r--+ 1 gabo staff 146 feb 24 11:24 test.tar.bz2


      file_from_internal is ok. It was created inside the directory and has right permissions and ACL.



      file_from_external ins't ok. It was moved from the parent directory, it carries the old permissions, and it hasn't the ACL. It seems that mv command doesn't work with ACL.



      test.tar.bz2 is strange. It was copied from the parent directory, it carries the old permissions, and it implements wrong ACL (file is not writeable by staff group):



      $ getfacl Acl/test.tar.bz2 
      # file: Acl/test.tar.bz2
      # owner: gabo
      # group: staff
      user::rw-
      group::rwx #effective:r--
      group:staff:rwx #effective:r--
      mask::r--
      other::r--


      It seems that cp also does't work with ACL



      test_tar directory also doesn't have group write permission, but it inherits ACL default behavior :/



      $ getfacl Acl/test_tar
      # file: Acl/test_tar
      # owner: gabo
      # group: staff
      # flags: -s-
      user::rwx
      group::rwx #effective:r-x
      group:staff:rwx #effective:r-x
      mask::r-x
      other::r-x
      default:user::rwx
      default:group::rwx
      default:group:staff:rwx
      default:mask::rwx
      default:other::r-x


      If I try to create a file inside test_tar using a different user (member of staff), I get a permission denied error.



      What's wrong in my setacl.sh script? Maybe there's some bug/gotcha/behavior that I'm not aware of?



      I would like to provide a replicable test suite in order to check it over different environments without typing a lot of shell commands.







      linux debian permissions acl






      share|improve this question















      share|improve this question













      share|improve this question




      share|improve this question








      edited Dec 15 at 22:19









      Rui F Ribeiro

      38.9k1479129




      38.9k1479129










      asked Feb 24 '17 at 11:23









      g4b0

      1366




      1366






















          1 Answer
          1






          active

          oldest

          votes


















          0














          This answer only addresses your tar issue.



          The tar utility does not retain extended attributes by default. Since SELinux contexts are stored in extended attributes, contexts can be lost when archiving files. Use the tar --selinux option to create archives that retain contexts and to restore files from the archives.






          share|improve this answer





















          • The problem is when I untar an archive created outside the directory managed with ACL. My expectations would be that the default ACLs were added, just like creating new files. The same problem arise with cp and mv, so I wonder how ACL can be useful in real word Linux/UNIX usarge...
            – g4b0
            Feb 27 '17 at 8:15












          • I just tried to tar/untar inside the directory managed with ACL, and it works like a charm. There is no necessity to use the --selinux flag.
            – g4b0
            Feb 27 '17 at 8:22











          Your Answer








          StackExchange.ready(function() {
          var channelOptions = {
          tags: "".split(" "),
          id: "106"
          };
          initTagRenderer("".split(" "), "".split(" "), channelOptions);

          StackExchange.using("externalEditor", function() {
          // Have to fire editor after snippets, if snippets enabled
          if (StackExchange.settings.snippets.snippetsEnabled) {
          StackExchange.using("snippets", function() {
          createEditor();
          });
          }
          else {
          createEditor();
          }
          });

          function createEditor() {
          StackExchange.prepareEditor({
          heartbeatType: 'answer',
          autoActivateHeartbeat: false,
          convertImagesToLinks: false,
          noModals: true,
          showLowRepImageUploadWarning: true,
          reputationToPostImages: null,
          bindNavPrevention: true,
          postfix: "",
          imageUploader: {
          brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
          contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
          allowUrls: true
          },
          onDemand: true,
          discardSelector: ".discard-answer"
          ,immediatelyShowMarkdownHelp:true
          });


          }
          });














          draft saved

          draft discarded


















          StackExchange.ready(
          function () {
          StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f347300%2facl-not-honored-by-mv-and-tar%23new-answer', 'question_page');
          }
          );

          Post as a guest















          Required, but never shown

























          1 Answer
          1






          active

          oldest

          votes








          1 Answer
          1






          active

          oldest

          votes









          active

          oldest

          votes






          active

          oldest

          votes









          0














          This answer only addresses your tar issue.



          The tar utility does not retain extended attributes by default. Since SELinux contexts are stored in extended attributes, contexts can be lost when archiving files. Use the tar --selinux option to create archives that retain contexts and to restore files from the archives.






          share|improve this answer





















          • The problem is when I untar an archive created outside the directory managed with ACL. My expectations would be that the default ACLs were added, just like creating new files. The same problem arise with cp and mv, so I wonder how ACL can be useful in real word Linux/UNIX usarge...
            – g4b0
            Feb 27 '17 at 8:15












          • I just tried to tar/untar inside the directory managed with ACL, and it works like a charm. There is no necessity to use the --selinux flag.
            – g4b0
            Feb 27 '17 at 8:22
















          0














          This answer only addresses your tar issue.



          The tar utility does not retain extended attributes by default. Since SELinux contexts are stored in extended attributes, contexts can be lost when archiving files. Use the tar --selinux option to create archives that retain contexts and to restore files from the archives.






          share|improve this answer





















          • The problem is when I untar an archive created outside the directory managed with ACL. My expectations would be that the default ACLs were added, just like creating new files. The same problem arise with cp and mv, so I wonder how ACL can be useful in real word Linux/UNIX usarge...
            – g4b0
            Feb 27 '17 at 8:15












          • I just tried to tar/untar inside the directory managed with ACL, and it works like a charm. There is no necessity to use the --selinux flag.
            – g4b0
            Feb 27 '17 at 8:22














          0












          0








          0






          This answer only addresses your tar issue.



          The tar utility does not retain extended attributes by default. Since SELinux contexts are stored in extended attributes, contexts can be lost when archiving files. Use the tar --selinux option to create archives that retain contexts and to restore files from the archives.






          share|improve this answer












          This answer only addresses your tar issue.



          The tar utility does not retain extended attributes by default. Since SELinux contexts are stored in extended attributes, contexts can be lost when archiving files. Use the tar --selinux option to create archives that retain contexts and to restore files from the archives.







          share|improve this answer












          share|improve this answer



          share|improve this answer










          answered Feb 25 '17 at 2:48









          fpmurphy

          2,353915




          2,353915












          • The problem is when I untar an archive created outside the directory managed with ACL. My expectations would be that the default ACLs were added, just like creating new files. The same problem arise with cp and mv, so I wonder how ACL can be useful in real word Linux/UNIX usarge...
            – g4b0
            Feb 27 '17 at 8:15












          • I just tried to tar/untar inside the directory managed with ACL, and it works like a charm. There is no necessity to use the --selinux flag.
            – g4b0
            Feb 27 '17 at 8:22


















          • The problem is when I untar an archive created outside the directory managed with ACL. My expectations would be that the default ACLs were added, just like creating new files. The same problem arise with cp and mv, so I wonder how ACL can be useful in real word Linux/UNIX usarge...
            – g4b0
            Feb 27 '17 at 8:15












          • I just tried to tar/untar inside the directory managed with ACL, and it works like a charm. There is no necessity to use the --selinux flag.
            – g4b0
            Feb 27 '17 at 8:22
















          The problem is when I untar an archive created outside the directory managed with ACL. My expectations would be that the default ACLs were added, just like creating new files. The same problem arise with cp and mv, so I wonder how ACL can be useful in real word Linux/UNIX usarge...
          – g4b0
          Feb 27 '17 at 8:15






          The problem is when I untar an archive created outside the directory managed with ACL. My expectations would be that the default ACLs were added, just like creating new files. The same problem arise with cp and mv, so I wonder how ACL can be useful in real word Linux/UNIX usarge...
          – g4b0
          Feb 27 '17 at 8:15














          I just tried to tar/untar inside the directory managed with ACL, and it works like a charm. There is no necessity to use the --selinux flag.
          – g4b0
          Feb 27 '17 at 8:22




          I just tried to tar/untar inside the directory managed with ACL, and it works like a charm. There is no necessity to use the --selinux flag.
          – g4b0
          Feb 27 '17 at 8:22


















          draft saved

          draft discarded




















































          Thanks for contributing an answer to Unix & Linux Stack Exchange!


          • Please be sure to answer the question. Provide details and share your research!

          But avoid



          • Asking for help, clarification, or responding to other answers.

          • Making statements based on opinion; back them up with references or personal experience.


          To learn more, see our tips on writing great answers.





          Some of your past answers have not been well-received, and you're in danger of being blocked from answering.


          Please pay close attention to the following guidance:


          • Please be sure to answer the question. Provide details and share your research!

          But avoid



          • Asking for help, clarification, or responding to other answers.

          • Making statements based on opinion; back them up with references or personal experience.


          To learn more, see our tips on writing great answers.




          draft saved


          draft discarded














          StackExchange.ready(
          function () {
          StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f347300%2facl-not-honored-by-mv-and-tar%23new-answer', 'question_page');
          }
          );

          Post as a guest















          Required, but never shown





















































          Required, but never shown














          Required, but never shown












          Required, but never shown







          Required, but never shown

































          Required, but never shown














          Required, but never shown












          Required, but never shown







          Required, but never shown







          Popular posts from this blog

          Morgemoulin

          Scott Moir

          Souastre