[comp.sys.hp] bug in hp nfs

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