Retaining file permissions

[Jonathan I. Kamens]

In article <1991Feb23.234242.812 at am.sublink.org>, alex at am.sublink.org (Alex Martelli) writes:
|> But you *can* keep your setuid bits, as well as the others, with a
|> little known (:-) Unix utility called "cat"; the crafty feline does
|> keep the target's permission bits - "cat xyzyx>$i" will do (a tip: use
|> something like xyzyx.$$ or sometime you'll get bitten by two of these
|> scripts running together in the same directory... brrr!).

  You must have a pretty strange version of cat on your system, or a
brain-damaged kernel that does not clear the setuid bit when a file is written
to.

% cp ~/.login frep
% chmod u+s frep
% ls -l frep
-rwsr--r--  1 jik          1820 Feb 26 10:36 frep
% cat ~/.login > frep
% ls -l frep
-rw-r--r--  1 jik          1820 Feb 26 10:37 frep

|> What behavior will Posix.2 mandate?

  I believe POSIX mandates that, for security reasons, the setuid and setgid
bits on a file should be cleared whenever the file is written to.  If that
isn't in the standard, then the standard is broken; then again, we already
knew that, so it isn't a surprise.  Further, I would find it very hard to
believe that POSIX says that cat is supposed to notice if stdout is a file and
do an fstat on it before it writes to it to get the permission bits, and then
do an fchmod afterwards to restore them to their initial conditions.

-- 
Jonathan Kamens			              USnail:
MIT Project Athena				11 Ashford Terrace
jik at Athena.MIT.EDU				Allston, MA  02134
Office: 617-253-8085			      Home: 617-782-0710