Re: ENFORCE_SAFE_MODE

> At 01:06 PM 8/30/00 -0700, Rasmus Lerdorf wrote: > > > I am getting rid of it and am only checking PG(safe_mode) in > > > fopen-wrappers.c. This should make the safe_mode much much safer from now > > > on (at least the code that uses the php_fopen_wrappers()). I have heard in > > > the past that some extension modules might want to open some system fonts > > > and stuff so you wouldn't want to enable safe mode for those modules but I > > > think it's a bad explanation. You could probably use those extensions to > > > open /etc/passwd and maybe even get some kind of info back by chance. > > > If anyone thinks I'll break something badly scream now! > > > >Whether it is a bad explanation or not, you will break the GD extension as > >I explained before. > > Well what do you suggest instead? Why not chown() the GD files over to > nobody if they should be used with the web site? ?? How does that solve anything? There is nothing special about the nobody user. Safe mode would still reject the file access. What is really required is a safemode file path of directories that are excluded from the safe mode check. Then admins can put font paths, temporary upload dirs, etc. on that path. > How do you know that the modules which don't have ENABLE_SAFE_MODE enabled > don't give you any way to see the raw data in the files? And it also seems > as if there were wholes with this in php_fopen_wrappers() under certain > circumstances (where include_path wasn't defined). I have never said there weren't holes. There are plenty. That's why just arbitrarily changing this one thing without providing a different way to achieve the same thing makes no sense to me. For example, what is the difference between ignoring safe mode on a file open from a specific PHP function and calling a lower level third-party api function which opens a file. We do the latter in dozens of places already. -Rasmus