Xref: utzoo comp.unix.shell:1608 comp.std.unix:1188
Path: utzoo!news-server.csri.toronto.edu!cs.utexas.edu!jsq
From: alex@am.sublink.org (Alex Martelli)
Newsgroups: comp.unix.shell,comp.std.unix
Subject: Re: Retaining file permissions
Keywords: chmod, sed, awk... and good old *cat*!
Message-ID: <18296@cs.utexas.edu>
Date: 2 Mar 91 15:48:33 GMT
References: <6039@ptsfa.PacBell.COM> <1991Feb22.041826.201@athena.mit.edu> <1991Feb23.234242.812@am.sublink.org> <1991Feb26.153931.27251@athena.mit.edu>
Sender: jsq@cs.utexas.edu
Followup-To: comp.std.unix
Organization: Premiata Famiglia Martelli & Figli
Lines: 45
Approved: jsq@cs.utexas.edu (Moderator, John S. Quarterman)
X-Submissions: std-unix@uunet.uu.net

Submitted-by: alex@am.sublink.org (Alex Martelli)

jik@athena.mit.edu (Jonathan I. Kamens) writes:
	...
	(I assert that cat one>two keeps all permission bits on two)
: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.

It's not the cat-s (I've tried both /bin/cat and /usr/local/gnubin/cat
and I have the source to the latter so I can check), so it must be
what you describe as "brain-damage" in the kernel.  Personally, I
don't see why open() or write() should ever change the file's permission
bits; sure it allows you to do silly things, but then if you care
about security you won't keep files that are executable, and world
writable, at the same time, will you?
Anyway the allegedly-broken kernel is Interactive 2.2, but I believe
others will behave similarly; I'll check at work.

:|> 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.

It would definitely make sense that cat a>b "do the natural thing" - IF
the kernel must muck with permission bit on write()s to b, then it
would hardly make sense for cat to have to undo it, and viceversa, if
the kernel leaves b's permission bits alone, then so should cat 
(should the SHELL try to change permission bits in the redirected-to
file before exec'ing cat??? I would DEFINITELY hope not!).  I have
redirected followups to comp.std.unix since it seems more of a standard
related question.  So, what DOES Posix say about this (open(), write(),
cat, shell redirection, and permission bits), and what SHOULD it say?
-- 
Alex Martelli - (home snailmail:) v. Barontini 27, 40138 Bologna, ITALIA
Email: (work:) martelli@cadlab.sublink.org, (home:) alex@am.sublink.org
Phone: (work:) ++39 (51) 371099, (home:) ++39 (51) 250434; 
Fax: ++39 (51) 366964 (work only), Fidonet: 332/401.3 (home only).

Volume-Number: Volume 22, Number 137