On Fri, 25 Nov 2005 09:39:34 -0800, in php.internals
[EMAIL PROTECTED] (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

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Reply via email to