On 2007-03-21 00:27:10 +0000, Dave wrote: > On Tue, Mar 20, 2007 at 12:14:17PM +0100, Oswald Buddenhagen wrote: > > On Tue, Mar 20, 2007 at 07:28:36AM +0000, Dave wrote: > > > On Mon, Mar 19, 2007 at 11:51:37PM -0400, Derek Martin wrote: > > > > I'd also really like to see a configure option for mutt refuse to > > > > run binaries in directories where the user has write access, > > > > > > I think that's a useful option. > > > > > it sort of defeats ~/bin. > > Well, you can "lock" ~/bin by chmod(1)ing u+w ~/bin before every > time you add or remove a local script/program, and u-w after you're > done.
So, what's the point of preventing Mutt from running binaries from such directories? Note that if the user saves a file from an external source to bin by mistake, the file won't have the x bit set. So, there's no problem. And if a chmod can be done on the file, it can also be done on the directory. > > the most secure solution is already the default: no sane program (except > > the linker) creates/saves files with an executable bit set. this is a > > conscious decision of the user - at the point where it is not, the > > security was already compromised. > > I don't disagree with your last statement. However, some people may > appreciate the added bit of security gained by extra restrictions on > program execution. If the user doesn't trust his $PATH or what he installs in his bin directory, he can still use full pathnames. But a *compile-time* option would be a bad idea, as the one who installs the software is not always the one who uses it. BTW, a shell with restrictions would be a much better idea. -- Vincent Lefèvre <[EMAIL PROTECTED]> - Web: <http://www.vinc17.org/> 100% accessible validated (X)HTML - Blog: <http://www.vinc17.org/blog/> Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon)
