Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!bfmny0!tneff From: tneff@bfmny0.UU.NET (Tom Neff) Newsgroups: alt.sources.d Subject: Re: shars and security concerns. Message-ID: <15446@bfmny0.UU.NET> Date: 3 May 90 02:11:53 GMT References: <662@n4hgf.uucp> <1152@chinacat.Unicom.COM> <518@cpsolv.CPS.COM> <1203@chinacat.Unicom.COM> <15441@bfmny0.UU.NET> Reply-To: tneff@bfmny0.UU.NET (Tom Neff) Lines: 18 In article faigin@aerospace.aero.org (Daniel P. Faigin) writes: >There are still major security concerns about this. Suppose you had an unshar >program that only allowed cat and chmod. That's it. You still have risks... ^^^^^^^ You need have no more risks than the unshar program is willing to allow. It could prevent setuid stuff, writing out of the current subtree, etc. >Shars are dangerous, and unshar programs don't get around the problem. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ This doesn't take my previous proposal into account. (Did the poster read it?) If standardized header information were provided as shell #comments, then an also-standardized unshar program could read a shar as effortlessly as a tar file, and with equally faithful results. Under this scheme there would be no "operations" at all, just file and directory creation. By imposing appropriate limits on what "Mode=" and "Name=" is allowed to be, unshar could operate safely.