dave@sea375.UUCP (David A. Wilson) (10/30/88)
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. I was logged on to microport as an unpriviledged user and expected the files to be owned by me, what a surprize! I did not use the 'p' option on tar and the tar program is not setuid or setgid. How can this happen? It seems like a rather large security hole to me! I have never seen this behavior on other systems, so what's the problem with microport? Are other utilities in microport allowed to do this also? Concerned, David A. Wilson dave@sea375.UUCP uw-beaver!tikal!slab!sea375!dave -- David A. Wilson uw-beaver!tikal!slab!sea375!dave
rcd@ico.ISC.COM (Dick Dunn) (11/03/88)
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. The assump- tion is that either you're running as root and you want to restore the original owners OR you're not root, the chowns will all fail, and you will end up owning the files. 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. What makes the Sys V chown seriously annoying in this context is that once you've chowned away a file, you can't chown it back to yourself (since you don't own it) - obvious enough; that's how it should be, but it means that if you chown both a directory and a file within that directory, you can't get rid of them without help from the receiving user or root. If the receiving user doesn't exist (e.g., restoring from a tar archive on another machine), root has to help you. (You can't delete the directory, even if it's within a directory you can write, because it isn't empty. You can't empty it because you don't own it or the file within it.) > It seems like a rather large security hole to me! I have never seen > this behavior on other systems, so what's the problem with microport? Strictly speaking, it's not a security hole. You can create files and make them owned by someone else, which certainly would let you subvert any per-user disk accounting. However, chown resets the setuid/setgid bits, so it's safe there. > Are other utilities in microport allowed to do this also? I don't know what other programs might do chowns, but the "facility" to give away files is there for any program or user that wants it. -- Dick Dunn UUCP: {ncar,nbires}!ico!rcd (303)449-2870 ...Nothing left to do but smile, smile, smile.
debra@alice.UUCP (Paul De Bra) (11/03/88)
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 | ------------------------------------------------------
bill@bilver.UUCP (Bill Vermillion) (11/04/88)
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... + The assump- +tion is that either you're running as root and you want to restore the +original owners OR you're not root, the chowns will all fail, and you will +end up owning the files. You can NOT restore the original owners of a file tar'ed from one machine and restored on another UNLESS the password files have the same identical user numbers in both. tar stores the files owner/group as numbers indexed into the password file. If john is 245 on the extract machine and mary is 245 on the destination, mary will be the owner. +If the receiving user doesn't exist (e.g., restoring from a tar archive on +another machine), root has to help you. (You can't delete the directory, +even if it's within a directory you can write, because it isn't empty. You +can't empty it because you don't own it or the file within it.) And the receiving user must have the same id number on both machines. -- Bill Vermillion - UUCP: {uiucuxc,hoptoad,petsd}!peora!rtmvax!bilver!bill : bill@bilver.UUCP
james@bigtex.cactus.org (James Van Artsdalen) (11/08/88)
In <287@bilver.UUCP>, bill@bilver.UUCP (Bill Vermillion) wrote: > You can NOT restore the original owners of a file tar'ed from one > machine and restored on another UNLESS the password files have the > same identical user numbers in both. This is not necessarily true with modern tar programs. > tar stores the files owner/group as numbers indexed into the password > file. POSIX compatible tar stores the user and group name as ASCII in addition to the number, and will restore to the user name if possible. I'm using a somewhat modified version of John Gilmore's tar, which was posted some time ago. -- James R. Van Artsdalen james@bigtex.cactus.org "Live Free or Die" Home: 512-346-2444 Work: 338-8789 9505 Arboretum Blvd Austin TX 78759