wohler@coco0.istc.sri.com (Bill Wohler) (05/27/88)
[part n of m issues from the gang at sri] okay, the following are three different attempts to extract a random tar file. as you scan the listing, decide which is the correct behaviour. ----- mystery machine a ----- [wohler@coco0:882]% cat xlock.tar.Z | tar xpvf - x xlock/xlock.c, 6940 bytes, 14 tape blocks x xlock/xlock.man, 1624 bytes, 4 tape blocks x xlock/Imakefile, 159 bytes, 1 tape blocks x xlock/Makefile, 412 bytes, 1 tape blocks [wohler@coco0:882]% l xlock total 11 -rw-rw-r-- 1 wohler istc 159 Apr 12 18:09 Imakefile -rw-rw-r-- 1 wohler istc 412 Apr 12 18:09 Makefile -rw-rw-r-- 1 wohler istc 6940 Apr 12 18:09 xlock.c -rw-rw-r-- 1 wohler istc 1624 Apr 12 18:09 xlock.man ---- mystery machine b ----- [wohler@cascades:130]$ zcat /milk/a/wohler/tmp/xlock.tar.Z | tar xvpf - x xlock/xlock.c, 6940 bytes, 14 tape blocks x xlock/xlock.man, 1624 bytes, 4 tape blocks x xlock/Imakefile, 159 bytes, 1 tape blocks x xlock/Makefile, 412 bytes, 1 tape blocks [wohler@cascades:131]$ l xlock total 22 -rw-rw-r-- 1 32 159 May 27 00:36 Imakefile -rw-rw-r-- 1 32 412 May 27 00:36 Makefile -rw-rw-r-- 1 32 6940 May 27 00:36 xlock.c -rw-rw-r-- 1 32 1624 May 27 00:36 xlock.man ----- mystery machine c ----- [wohler@coco0:887]% zcat ~/tmp/xlock.tar.Z |tar xvpf - tar: can't create xlock/xlock.c: Permission denied tar: can't create xlock/xlock.man: Permission denied tar: can't create xlock/Imakefile: Permission denied tar: can't create xlock/Makefile: Permission denied tar: can't set time on xlock: Not owner [wohler@coco0:888]% ls -lgd xlock drwxrwxr-x 2 903 32 64 May 27 00:38 xlock/ which one did you think was correct? i think machine a is correct since it restores the original date of the tar files. since i'm not root it sets the ownership of the files to me. if i extract a tar as me, i won't be able to edit the files if they are owned by some random joe. in the worst case, machine c, i couldn't even extract the stuff because the directory had been set to the owner of the original tar file, and i sure can't write files in there! now the answers to today's quiz are: a: sun hardware, file on sun via nfs. b: hp hardware, file on hp disk. c: sun hardware, file on hp via nfs. --bw
rml@hpfcdc.HP.COM (Bob Lenk) (05/28/88)
a: sun hardware, file on sun via nfs.
b: hp hardware, file on hp disk.
c: sun hardware, file on hp via nfs.
This seems to be related to System V compatibility using chown(2).
System V permits the owner of a file to give it away, while BSD systems
(including Sun) restrict this to the superuser. Thus on System V (and
compatible systems like HP-UX), the "p" option to tar does a chown for
any user (as documented). On BSD systems it only overrides the umask
while restoring file permissions. Given this capability, I think System
V tar orders the operations so the directory is written first, its time
and permissions are modified second, at it is chown'd last. From result
(c), Sun's tar apparently assumes chown(2) will only work for superuser,
(which is not true on a heterogeneous network), and thus doesn't order
operations and assumes it will fail for mortal users.
Dropping the "p" option should give you what you want. For a 100%
solution do a umask 0 first if that's not your default (and restore it
afterwards).
HP-UX will also let the administrator restrict chown to superuser
(equivalent to BSD and Sun) with setprivgrp(1m). I haven't tried this,
but it would probably give you the expected behavior with (c) but
warning messages with (b).
Bob Lenk
{ihnp4, hplabs}!hpfcla!rml
rml%hpfcla@hplabs.hp.com