Retaining file permissions

The Grand Master asg at sage.cc.purdue.edu
Sat Mar 2 02:08:33 AEST 1991


In article <1991Feb28.221952.29685 at athena.mit.edu> jik at athena.mit.edu (Jonathan I. Kamens) writes:
}In article <7120 at mentor.cc.purdue.edu>, asg at 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.
}
You said (paraphrased) that we must turn off the suid bit upon write to 
a non-executable file less someone chmod that file to make it executable.
I said (now listen, this is very simple)
If they can chmod it to executable, they can chmod it to suid. 
Your reasoning is therefore faulty
Or is that too hard for an MIT student to understand
		Bruce Varney
		   The Grand Master



More information about the Comp.unix.shell mailing list