Retaining file permissions
Jonathan I. Kamens
jik at athena.mit.edu
Wed Feb 27 02:39:31 AEST 1991
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
More information about the Comp.unix.shell
mailing list