Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!helios!bcm!dimacs.rutgers.edu!seismo!uunet!snorkelwacker.mit.edu!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
Keywords: chmod, sed, awk... and good old *cat*!
Message-ID: <1991Feb28.205734.26484@athena.mit.edu>
Date: 28 Feb 91 20:57:34 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>
Sender: news@athena.mit.edu (News system)
Organization: Massachusetts Institute of Technology
Lines: 39

In article <21789@yunexus.YorkU.CA>, oz@yunexus.yorku.ca (Ozan Yigit) writes:
|> In article <see ref> jik@athena.mit.edu (Jonathan I. Kamens) writes:
|> >  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.
|> Any file, or just those files that are also executable?

  From write(2):

     If the real user is not the super-user, then write clears
     the set-user-id bit on a file.  This prevents penetration of
     system security by a user who captures a writable set-user-
     id file owned by the super-user.

  If it only did it on executable files, then if there were a file on the disk
that was setuid but not executable, a not-nice person could (a) figure out
some way to write his own program into the file, and (b) use chmod to make it
executable.  this defeats the purpose of the clearing of the set-user-id bit.

|> >If that
|> >isn't in the standard, then the standard is broken; then again, we already
|> >knew that, so it isn't a surprise.
|> Really? How about a list of all those things you already knew to be
|> broken in the standard? I am much interested.

  I can't tell whether or not you're being sarcastic here, but let me clue you
in on something -- I was.

  In any case, one thing I consider broken about POSIX is that there's no
st_blocks field in its stat structure; more generally, there is no standard
way in POSIX to find out how much space a file actually occupies on the disk
(i.e. taking into account holes in the file that don't take up any space on
the disk).  I consider this a major lose.

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