ACL not honored by mv and tar
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
add a comment |
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
add a comment |
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
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
linux debian permissions acl
edited Dec 15 at 22:19
Rui F Ribeiro
38.9k1479129
38.9k1479129
asked Feb 24 '17 at 11:23
g4b0
1366
1366
add a comment |
add a comment |
1 Answer
1
active
oldest
votes
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.
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
add a comment |
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
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
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
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.
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
add a comment |
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.
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
add a comment |
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.
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.
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
add a comment |
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
add a comment |
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.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
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
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
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