Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!pacific.mps.ohio-state.edu!linac!att!ucbvax!SHUM.HUJI.AC.IL!amoss From: amoss@SHUM.HUJI.AC.IL (Amos Shapira) Newsgroups: comp.os.minix Subject: Re: Security hole ?! Keywords: Program: rm" Message-ID: Date: 14 Apr 91 18:39:55 GMT References: <553@ultrix.uhasun.hartford.edu> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Hebrew University of Jerusalem, Israel Lines: 21 mgallagh@uhasun.hartford.edu (Michael Gallagher) writes: > Using two accts that were not priv'd, I found that while files created >by one could not be read, etc with by the other if protections were not set >for world or group [umask = 77], they COULD be rm'd. In fact, you are >prompted as to whether you wish to actually remove this file DESPITE that >it's protection code is 700 [no world or group access]. The action of removing a file actually writes its "parent": the directory which holds the name of the file. This is not a security hole but part of the design. To not allow the world to remove a file you should deal with the permissions of the directory containing its name, that's why anyone can read /etc/passwd and other important files but can't, on a properly managed system, remove these files or change their names. Hope this explains, > -mg -Amos Shapira amoss@cs.huji.ac.il