Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sun-barr!olivea!mintaka!bloom-beacon!bloom-picayune.mit.edu!athena.mit.edu!jik
From: jik@athena.mit.edu (Jonathan I. Kamens)
Newsgroups: comp.unix.shell
Subject: Re: Retaining file permissions
Message-ID: <1991Feb28.221952.29685@athena.mit.edu>
Date: 28 Feb 91 22:19:52 GMT
References: <6039@ptsfa.PacBell.COM> <1991Feb22.041826.201@athena.mit.edu> <1991Feb23.234242.812@am.sublink.org> <1991Feb26.153931.27251@athena.mit.edu> <21789@yunexus.YorkU.CA> <1991Feb28.205734.26484@athena.mit.edu> <7120@mentor.cc.purdue.edu>
Sender: news@athena.mit.edu (News system)
Organization: Massachusetts Institute of Technology
Lines: 40

In article <7120@mentor.cc.purdue.edu>, asg@sage.cc.purdue.edu (The Grand Master) writes:
|> [a vitriolic flame criticizing my intelligence and understanding of Unix]

  Sigh.  It's amazing how people find it necessary to flame where a simple
question would suffice.

  Taking your posting and translating it into polite terms, you're asking,
"Why are you saying that someone could chmod it if they don't own it."

  Among other things, the reason writes to a file turn off the set-user-id bit
is to protect Unix from security holes that we *don't* know about.  There may
be a way that we *don't* know about yet for a user to modify or change the
permissions on a file when he should not be able to.  We *don't know about the
hole yet*, so we *don't know what form it takes*.  In other words, we don't
know what conditions would allow the user to do this.  We don't know whether
it's a user space bug or a kernel but that would allow the user to do this. 
And we don't know what to to prevent the user from being allowed to do this.

  For this reason, there is a very *low-level* safety valve in the kernel. 
"If the file is set-user-id (or set-group-id, I believe), and any sort of
write is attempted, the set-user-id or set-group-id bits are turned off.  This
prevents users from taking advantage of *other bugs that we don't know about*
to use the set-user-id or set-group-id bits to their advantage.

  If we assume that the system is secure, then we do not need to turn off the
setuid and setgid bits on writes to files, since obviously only people who are
allowed to do the writes and who are allowed to use the setuid and setgid bits
are doing it.  If, on the other hand, we assume that the system is not secure,
then we must turn off the setuid and setgid bits when writing to *any* file,
executable or not, as a simple security precaution.

|> And I thoug MIT taught people to think before they speak.

  Preacher, heal thyself.

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