* Thus wrote Rx ([EMAIL PROTECTED]):
>
> "Curt Zirzow" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]
> > * Thus wrote Rx ([EMAIL PROTECTED]):
> >
> > You can set the value with
> > php_admin_value save_path "/tmp"
>
> If i set php_admin_value, user STILL can change the value with ini_set()! I
> tested it. php_admin_value only prevents changing value from .htaccess file.
> Actually this also make sense for me, values set by php_admin_value shouldnt
> be allowed to change ever.
I was not aware of this.
>
> >
> > >
> >
>
> You didnt understand. I change save.session_path to other's site session
> directory, do session_start(), write every variable what i want, write down
> session number, go to this site and using this generated session. You cannt
> prevent this ever!
hm. yes, I see your point on this.
>
> > > 2. Delete other users sessions by setting gc to 100 and probably legal
> files
> > > starting with sess_*.
> >
> > I'm also not sure but technically gc_maxlifetime should never be
> > lower than cache_expire, if this is the case then there no issues
> > with setting gc_probablity to 100, cept for a bunch of overhead for
> > the users script.
> >
> Hm, what the connection with cache_expire? User set gc to 100 and
> maxlifetime to 1 sec, then that script will delete every session in
> directory.
The conection is that the gc shouldn't clean up a session that has
a lifetime still. so if gc_maxlifetime = 9 and cache_expire = 10,
gc shouldn't clean up anything less than 11.
But then, this is a mute point since if you change cache_expire
at run time, gc wont know the difference.
>
> > Don't allow the person to create files. That is the only way to
> > prevent a user of doing this regardless of the save_path parameter.
> >
>
> No, its not a valid point. Every user can access only certain directory with
> apache permissions or with his own. And i know which directory belongs to
> whom. However with session.save_path user can flood EVERY directory on
> server, and even i wont know which user did that!
Thanks for clarifying this. I was not thinking on the same line as
you. So a malicious user can do something like:
while (1) {
session_save_path(pick_a_writeabledir());
session_start();
session_write_close();
}
Curt
--
"I used to think I was indecisive, but now I'm not so sure."
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php