Changes in the way tar(1) constructs directory permissions
There has been changes in the way a tar(1) restore to a temporary
directory constructs directory ownerships; as login theuser, in
${HOME}:
mkdir xxx xxx/yyy; touch xxx/yyy/zzz
su
Password:
# cd /
# tar cvf home/theuser/aaa.tar home/theuser/xxx
home/theuser/xxx/
home/theuser/xxx/yyy/
home/theuser/xxx/yyy/zzz
# cd /home/theuser/
# mv xxx xxx.bak
# tar xvf aaa.tar
home/theuser/xxx/
home/theuser/xxx/yyy/
home/theuser/xxx/yyy/zzz
# ls -al home /home
/home:
total
drwxr-xr-x 6 rootroot 4096 Nov 6 23:52 ./
drwxr-xr-x 28 rootroot 4096 Nov 7 10:41 ../
drwxr-xr-x 72 theuser users16384 Nov 8 00:14 theuser/
home:
total
drwxr-xr-x 3 root root 4096 Nov 8 00:14 ./
drwxr-xr-x 72 theuser users 16384 Nov 8 00:14 ../
drwxr-xr-x 3 root root 4096 Nov 8 00:14 theuser/
^
^
^
I verified that the ownership of the restored directory, theuser/, was
correct in a 2012 version of Linux.
John
--
John Conover, cono...@rahul.net, http://www.johncon.com/
--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20141108083251.16945.qm...@rahul.net
Re: Changes in the way tar(1) constructs directory permissions
On Sat, 08 Nov 2014, John Conover wrote:
There has been changes in the way a tar(1) restore to a temporary
directory constructs directory ownerships; as login theuser, in
${HOME}:
This looks like you're using tar --no-same-owner, possibly via an ENV
variable or something else.
% fakeroot bash -c 'touch foo; chown 9 foo; ls -l foo; tar -zcf bar.tar.gz foo;
rm foo; tar -zxf bar.tar.gz; ls -l foo; rm foo';
-rw-r--r-- 1 news root 0 Nov 8 09:43 foo
-rw-r--r-- 1 news root 0 Nov 8 09:43 foo
works just fine here with tar 1.27.1-2.
--
Don Armstrong http://www.donarmstrong.com
First you take a drink,
then the drink takes a drink,
then the drink takes you.
-- F. Scott Fitzgerald
--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20141108174630.gt29...@teltox.donarmstrong.com
Re: Changes in the way tar(1) constructs directory permissions
Don Armstrong writes:
On Sat, 08 Nov 2014, John Conover wrote:
There has been changes in the way a tar(1) restore to a temporary
directory constructs directory ownerships; as login theuser, in
${HOME}:
This looks like you're using tar --no-same-owner, possibly via an ENV
variable or something else.
% fakeroot bash -c 'touch foo; chown 9 foo; ls -l foo; tar -zcf bar.tar.gz
foo; rm foo; tar -zxf bar.tar.gz; ls -l foo; rm foo';
-rw-r--r-- 1 news root 0 Nov 8 09:43 foo
-rw-r--r-- 1 news root 0 Nov 8 09:43 foo
That's true, Don, but the issue is the ownership of the DIRECTORIES
when installing, a directory TREE in a non root temporary
directory. The file ownerships are, indeed, correct. The ownerships of
the directories down to the files are always root/root.
John
--
John Conover, cono...@rahul.net, http://www.johncon.com/
--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20141108183615.6763.qm...@rahul.net
Re: Changes in the way tar(1) constructs directory permissions
On Sat, 08 Nov 2014, John Conover wrote: That's true, Don, but the issue is the ownership of the DIRECTORIES when installing, a directory TREE in a non root temporary directory. The file ownerships are, indeed, correct. The ownerships of the directories down to the files are always root/root. % fakeroot bash -c 'mkdir -p foo/bar; chown 8:8 .; chown 9:9 foo; chown 10:10 foo/bar; ls -la foo; tar -zvvtf bar.tar.gz; tar -zcf bar.tar.gz foo; rmdir -p foo/bar; tar -zxf bar.tar.gz; ls -la foo; rmdir -p foo/bar;'; total 12 drwxr-xr-x 3 news news 4096 Nov 8 11:07 . drwxr-xr-x 7 mail mail 4096 Nov 8 11:07 .. drwxr-xr-x 2 uucp uucp 4096 Nov 8 11:07 bar drwxr-xr-x news/root 0 2014-11-08 11:07 foo/ drwxr-xr-x uucp/root 0 2014-11-08 11:07 foo/bar/ total 12 drwxr-xr-x 3 news news 4096 Nov 8 11:07 . drwxr-xr-x 7 mail mail 4096 Nov 8 11:07 .. drwxr-xr-x 2 uucp uucp 4096 Nov 8 11:07 bar It would be helpful if you provided a self-contained example like this which showed the behavior you are seeing. It would also be useful to see the output of env|grep -i TAR; the output of tar --version; and the output of dpkg -l tar;. -- Don Armstrong http://www.donarmstrong.com LEADERSHIP -- A form of self-preservation exhibited by people with autodestructive imaginations in order to ensure that when it comes to the crunch it'll be someone else's bones which go crack and not their own. -- The HipCrime Vocab by Chad C. Mulligan (John Brunner _Stand On Zanzibar_ p256-7) -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141108191008.gu29...@teltox.donarmstrong.com
Re: Changes in the way tar(1) constructs directory permissions
Don Armstrong writes: On Sat, 08 Nov 2014, John Conover wrote: That's true, Don, but the issue is the ownership of the DIRECTORIES when installing, a directory TREE in a non root temporary directory. The file ownerships are, indeed, correct. The ownerships of the directories down to the files are always root/root. su cd / tar cvf xxx.tar etc/cups/printers.conf cd tar xvf /xxx.tar ls -al etc and look at the ownership of the cups directory and compare it to the ownership in /etc. This is a changed behavior in tar(1), (at least from Ubuntu 10.04 LTS, which I just verified.) Note that it only happens when when tar'ing file names in a directory, and not the directory itself, (tar cvf xxx.tar etc/cups, and restoring, everything has the correct ownership/permissions.) See, also: http://www.gnu.org/software/tar/manual/html_node/Directory-Modification-Times-and-Permissions.html for some details, where it would seem that the behavior is acceptable-at issue is that it changed between the last versions of Linux, and the newer. Thanks, Don, John -- John Conover, cono...@rahul.net, http://www.johncon.com/ -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141108194012.9306.qm...@rahul.net
Re: Changes in the way tar(1) constructs directory permissions
On Sat, 08 Nov 2014, John Conover wrote: and look at the ownership of the cups directory and compare it to the ownership in /etc. In this example, you're not archiving etc/cups or etc, you're just archiving etc/cups/printers.conf, which means that tar must create etc/cups itself, and has no record of what the original permissions of etc/cups were. I've verified that this behaves the same way in 1.23-3 and 1.26+dfsg-0.1 as it does in 1.27-1. If you want to keep the permissions of etc/cups, then you want: sudo bash -c 'tar -C / --no-recursion -cvf xxx.tar.gz etc/cups/printers.conf etc/cups; tar -vtf xxx.tar.gz; tar -vxf xxx.tar.gz; ls -lR etc;' for some details, where it would seem that the behavior is acceptable-at issue is that it changed between the last versions of Linux, and the newer. I have no idea what you mean by last versions of Linux. The output of dpkg -l tar; or tar --version; will tell us what version(s) of tar you're using. -- Don Armstrong http://www.donarmstrong.com It's not Hollywood. War is real, war is primarily not about defeat or victory, it is about death. I've seen thousands and thousands of dead bodies. Do you think I want to have an academic debate on this subject? -- Robert Fisk -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141108201110.gw29...@teltox.donarmstrong.com
