Re: Re: PDM Meeting Notes

On Fri, 25 Nov 2005 09:39:34 -0800, in php.internals rasmus@lerdorf.com (Rasmus Lerdorf) wrote: >I think that is a pretty good idea actually. It's the uid matching that >is the problem. Having a way to restrict which commands the exec >functions can execute is sort of a separate thing that is snapped onto >the end of safe_mode. Nice - I like this solution much more than users should maintain their own disabled_functions list. Oh, and a rename of the directive would be much appreciated - at least it'll kill the apparently unavoidable semantics discussion every time "safe" is mentioned. >We're a little distracted by 5.1, but if you or someone else can keep >this in mind and remind us later, I would appreciate it. Or come up >with a patch for HEAD we can look at. FWIW, I'll make some noise later :-) I'm still not clear about the open_basedir issue though: open_basedir seems useless if users have access to e.g. cat and ls (or glob() :-) The solution with users running scrips only readably by themselves and php running as the user seems as a whole alternative to open_basedir. Furthermore there is the security issue of the user running the script also able to modify or create new files. In summary: == open_basedir+some_exec_dir_restriction == Source of vulnerability: shortcomings regarding third part modules or new functions not added to list of exec functions. Impact: possible read access for files and directories outside of open_basedir. Fix: centralized (the php core source, third party modules) == PHP running as user, scripts non-readable by "other" == Source of vulnerability: bugs in php script Impact: possible read and write access to all files owned by current user Fix: decentralized (the current php script) I guess my main concern is that open_basedir is kept in PHP6 (based on the talks), but it is pretty much useless if not backed up by other tools (disable_exec_functions, some_exec_dir_restriction, ...) -- - Peter Brodersen