[2115] in Athena Bugs
cp and tar
daemon@ATHENA.MIT.EDU (Joe Harrington)
Tue Apr 25 19:21:09 1989
Date: Tue, 25 Apr 89 19:20:16 EDT
From: Joe Harrington <jh@ATHENA.MIT.EDU>
To: bugs@ATHENA.MIT.EDU
Cc: jh@ATHENA.MIT.EDU
Reply-To: jh@ATHENA.MIT.EDU
I found the following {bug, misfeature} in cp after finding that the
following bug in tar made it useless for what I was doing. Both were
originally discovered on pika's vax 3.0.4.1 release. I have
reproduced the cp bug on vax 6.0R. You will need a disk with bad
blocks to reproduce the tar error. Thank god I don't have one at the
moment... ;-)
The tar bug:
Upon attempting to read a bad block, tar writes out a truncated block,
instead of a right-sized block of place-holders. This puts out an
illegal tar archive, which tar cannot read beyond the truncated block.
Tar archives have headers with inode info and size of file following.
When the bad block is hit, the file size changes from what tar thought
it was getting, but too late -- the header has already been written.
Ideally, tar would give an error message if it either put a bad-block
placeholder on the archive or if it read one, though the latter might
be tough. In any case, a full block should be written.
The cp bug/misfeature:
cp copies a file, giving the new file the user and group id of the
process. cp -p does the favor of keeping the permissions and dates
the same. Including setuid and sticky bits. Thus, if root ever runs
cp -p on a setuid program, it ends up setuid to root. The potential
danger is obvious, though not enough so that anyone I have told this
too had thought of it beforehand. I think that if the behavior of cp
is not changed, at least this problem should be mentionned in the man
page, so people will explicitly be aware of the danger.
--jh--
