Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!yale!think.com!linus!nixbur!nixpbe!peun33!israel From: israel.pad@nixdorf.com (Andreas Israel) Newsgroups: comp.unix.questions Subject: Re: /bin read bits Message-ID: Date: 11 Dec 90 06:33:48 GMT References: Sender: news@nixpbe.sni.de Lines: 23 In aglew@crhc.uiuc.edu (Andy Glew) writes: >>Is there any good reason why UNIX systems are shipped with the read bit set >>for 'other' in /bin and /usr/bin binaries? >On the other hand, a reason for letting the world read binaries: I >frequently am asked to help people use UNIX tools - sometimes the old >[...] >found". Usually my first step is to run strings on the binary, to >find out what files it is looking for. > Is this a good reason? Not if you've got a bullet-proof product. Last week I had a similar problem. I was asked to help solving a problem (a debugger failed to execle the debugged program). The problem was the following: The debugger (GNU's gdb) calls the program via "execle("/bin/sh", "sh", "-c", cmd, 0, envp)". And our system will not do the exec after a ptrace call, if the user has no read access to the called program (in this case /bin/sh). There may be some security problems with set-UID programs, if these programs are not carefully programmed. But these problems remain even without read access. It's only harder to find it out. The solution is not to deny read access.