* 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