Path: utzoo!utgpu!attcan!uunet!ncrlnk!ncr-sd!hp-sdd!ucsdhub!ucsd!ames!mailrus!tut.cis.ohio-state.edu!rutgers!bellcore!faline!thumper!ulysses!andante!alice!debra
From: debra@alice.UUCP (Paul De Bra)
Newsgroups: comp.unix.microport
Subject: Re: Security hole in tar on Microport
Message-ID: <8382@alice.UUCP>
Date: 3 Nov 88 03:33:48 GMT
References: <226@sea375.UUCP> <10750@ico.ISC.COM>
Reply-To: debra@alice.UUCP ()
Organization: AT&T, Bell Labs
Lines: 29

In article <10750@ico.ISC.COM> rcd@ico.ISC.COM (Dick Dunn) writes:
]In article <226@sea375.UUCP>, dave@sea375.UUCP (David A. Wilson) writes:
]> I have a problem with using tar on microport. I created a tar floppy
]> on a system as an unpriviledged user. When I extracted the floppy on
]> another system running Microport System V/AT version 2.3 all the files
]> extracted were owned by the userid of the other system...
]
]Remember that tar is a V7-ish program.  It just extracts files and chowns
]them back to the original owners as recorded on the archive...
]
]Under V7 (and BSD) chown is effectively restricted to root; you can't give
]away files.  Thus tar, as it is written, works sensibly.  Under Sys V, you
]can chown a file to someone else if you own it.  You may regard this as a
]feature or a bug in chown, but in any case it's a mismatch to the way tar
]is written.
]
There used to be a serious security problem with this (could I say faulty?)
behaviour of chown, when combined with the "at" command. I don't know about
the more recent Unix versions but I was once using a System III version where
you could submit a job with "at", this created a "job" file in some spool
directory, which you could subsequently edit and then chown to root. Then
at the correct time "atrun" would think this was a job for root and thus
execute it as root...

Paul.
-- 
------------------------------------------------------
|debra@research.att.com   | uunet!research!debra     |
------------------------------------------------------