Notes |
(0008474)
vda
06-23-08 10:41
|
> What's perplexing is what's the "right" thing to do?
Right thing to do is to adhere to standards, and to GNU tools' behavior (in this order of importance). |
| |
(0008484)
vda
06-23-08 10:57
|
I just tried - GNU tar also restores mode of the files and dirs even if they already existed.
So, "standard" dpkg does not use tar but performs tar unpacking internally, and it does not restore modes? Can you upload an example file and specify how to reporduce the problem?
BTW, tghanks for looking into dpkg, it needs some work... |
| |
(0008494)
wz2b
06-24-08 09:21
|
I'm confused that you don't see the same behavior with tar as I do, so to begin, I have uploaded a small shell script to test the behavior. This script produces different results between gnu tar 1.15.1 and busybox. On gnu tar, I get:
==== Test 2 - directory already exists ====
drwx------ 2 cepasp ahm 4096 2008-06-24 12:16 ./tar_test
This directory should have permissions 0700
because tar did not overwrite the existing directory
which is what I hoped; tar saw that the directory tar_test already existed so it did not alter its permissions (or owner, but it's easier to test this when you change the permissions, because you don't have to be root as you would when changing owner).
Now, running the same script on busybox, I get this result:
==== Test 2 - directory already exists ====
drwxr-xr-x 2 root root 1024 Jun 24 16:10 ./tar_test
This directory should have permissions 0700
because tar did not overwrite the existing directory
So what busybox's tar did was to replace the existing permissions with those in the archive.
It's interesting that you note that "standard" dpkg doesn't call tar, but does the untarring internally. Maybe that's the answer here, too -- maybe busybox's dpkg needs to do something slightly different than the internal tar. |
| |
(0008504)
vda
06-24-08 11:32
|
I added
tar --version 2>&1 | head -3
tar --help 2>&1 | head -3
so that version will be visible, then ran:
Busybox:
# sh tartest.sh
tar: unrecognized option `--version'
BusyBox v1.11.0.svn (2008-04-29 04:44:30 CEST) multi-call binary
BusyBox v1.11.0.svn (2008-04-29 04:44:30 CEST) multi-call binary
Usage: tar -[czjaZxtvO] [-X FILE] [-f TARFILE] [-C DIR] [FILE(s)]...
==== Test 1 - directory gets permissions in tarball ====
drwxr-xr-x 2 root root 72 Jun 24 20:29 ./tar_test
This directory should have permissions 0755
because that's what is in the tarball
==== Test 2 - directory already exists ====
drwxr-xr-x 2 root root 72 Jun 24 20:29 ./tar_test
This directory should have permissions 0700
because tar did not overwrite the existing directory
GNU:
# PATH=/usr/bin:$PATH sh tartest.sh
tar (GNU tar) 1.15.1
Usage: tar [OPTION...] [FILE]...
GNU `tar' saves many files together into a single tape or disk archive, and can
restore individual files from the archive.
==== Test 1 - directory gets permissions in tarball ====
drwxr-xr-x 2 root root 72 2008-06-24 20:28 ./tar_test
This directory should have permissions 0755
because that's what is in the tarball
==== Test 2 - directory already exists ====
drwxr-xr-x 2 root root 72 2008-06-24 20:28 ./tar_test
This directory should have permissions 0700
because tar did not overwrite the existing directory
Conclusion: with your script even GNU tar overwrites permissions
of existing directory. At least GNU tar 1.15.1 |
| |
(0008514)
wz2b
06-24-08 11:54
|
Wow, I am totally mind-boggled because this is not what I get. On my ubuntu system with gnu tar 1.15.1:
$ ./tartest.sh
==== Test 1 - directory gets permissions in tarball ====
drwxr-xr-x 2 cepasp ahm 4096 2008-06-24 14:53 ./tar_test
This directory should have permissions 0755
because that's what is in the tarball
==== Test 2 - directory already exists ====
drwx------ 2 cepasp ahm 4096 2008-06-24 14:53 ./tar_test
This directory should have permissions 0700
because tar did not overwrite the existing directory
$ tar --version
tar (GNU tar) 1.15.1
What on earth could be causing us to get different behavior? |
| |
(0008524)
vda
06-24-08 12:06
|
Made tar run under strace:
chmod ${MODE2} ${DIR}
strace -o tar.strace tar -zxf ${DIR}.tgz
^^^^^^^^^^^^^^^^^^^^
The end of strace log is as follows:
mkdir("./tar_test", 0755) = -1 EEXIST (File exists)
stat64("./tar_test", {st_mode=S_IFDIR|0700, st_size=48, ...}) = 0
open("./tar_test/testfile", O_WRONLY|O_CREAT|O_EXCL|O_LARGEFILE, 0644) = 5
close(5) = 0
utime("./tar_test/testfile", [2008/06/24-21:02:28, 2008/06/24-21:02:28]) = 0
chown32("./tar_test/testfile", 0, 0) = 0
read(3, "", 10240) = 0
gettimeofday({1214334148, 991164}, NULL) = 0
gettimeofday({1214334148, 991216}, NULL) = 0
close(3) = 0
waitpid(7168, [{WIFEXITED(s) && WEXITSTATUS(s) == 0}], 0) = 7168
utime("./tar_test", [2008/06/24-21:02:28, 2008/06/24-21:02:28]) = 0
chmod("./tar_test", 0755) = 0 <===================== HERE
chown32("./tar_test", 0, 0) = 0
close(1) = 0
close(2) = 0
exit_group(0) = ?
It sees that dir exists, with mode 700.
It definitely does chmod("./tar_test", 0755).
What do you see?
Does it differ under root and non-root? |
| |
(0008534)
wz2b
06-24-08 12:15
|
>Does it differ under root and non-root?
Yep, you nailed it. That's the difference.
I was running these tests as myself If you're non-root, strace shows that tar performs no chmod. It just fails on creation of the directory, and moves on silently:
mkdir("./tar_test", 0755) = -1 EEXIST (File exists)
stat64("./tar_test", {st_mode=S_IFDIR|0700, st_size=4096, ...}) = 0
So ... now what? I guess I should see what dpkg does on ubuntu compared to busybox and see what happens. I'll try that, and when I figure something out I'll post the results -- and upload a tiny sample .deb |
| |
(0008544)
vda
06-24-08 12:19
|
Please attach full strace output |
| |
(0008554)
vda
06-24-08 13:30
|
Even better, attach full strace outputs of busybox and GNU tar, under root and non-root |
| |
(0014124)
vda
10-24-08 16:52
|
Fixed in rev.23783, thanks |
| |
tartest.sh [^] (715 bytes) 06-24-08 09:14 
