Jul 24, 2002, 9:54 AM
Administrator (9387 posts)
Jul 24, 2002, 9:54 AM
Post #27 of 28
Views: 3151
Hi Dan,
Like Adrian said, we are going to make this change as it's easy to accomodate. I just find it shocking that under safe_mode, any files that php create, it can not read. This really limits a lot of applications that aren't database driven, i.e. mail systems that store the mail on disk, bulletin boards that store posts on disk, and even us implementing an admin area for Links SQL! How is Links SQL going to build pages if the next time it tries and build pages it won't be able to overwrite the file!
This is really a poor setup choice by your ISP, as it really limits alot of the functionality in php for no benefit (as a user can get around the restriction using CGI).
Cheers,
Alex
--
Gossamer Threads Inc.
Like Adrian said, we are going to make this change as it's easy to accomodate. I just find it shocking that under safe_mode, any files that php create, it can not read. This really limits a lot of applications that aren't database driven, i.e. mail systems that store the mail on disk, bulletin boards that store posts on disk, and even us implementing an admin area for Links SQL! How is Links SQL going to build pages if the next time it tries and build pages it won't be able to overwrite the file!
This is really a poor setup choice by your ISP, as it really limits alot of the functionality in php for no benefit (as a user can get around the restriction using CGI).
Cheers,
Alex
--
Gossamer Threads Inc.
Jul 24, 2002, 2:24 PM
Enthusiast (944 posts)
Jul 24, 2002, 2:24 PM
Post #28 of 28
Views: 3134
Hi Alex,
I appreciate your willingness to make the change for future releases.
Well, I'm not hear to claim it's the best solution, but it's the one the creators of PHP felt provides the best security and my sysAdmin (who's background is in network security probing) felt is necessary. Both parties know a lot more about the pertinent points to consider than I do, so I'm not here to second guess them...
Agreed. However, that's really neither here nor there... It means certain things are more challenging, but I view that as a necessary evil with my own programming if I don't want to limit the target audience.
Are there any flatfile PHP forum systems out there?
Are you looking into making the Perl admin area PHP based to match the PHP front end? I assume you're also considering ways of allowing static-built PHP pages? I could see that being quite difficult from a safe mode standpoint... One key difference there is that that is an option. I.e. users can choose to go static or dynamic, but static would not work for them if there server is running under safe mode. With the current compiled files discussion, there is no option of whether or not to use it, so it's important that it be made to work for everyone.
I don't really agree with that, as I think it's juxtaposing and confusing separate issues. Sure, CGI scripts can get around PHP's safe mode restrictions, but that has nothing to do with the matter of why PHP locks down such things. It's because of PHP's security considerations, not Perl's. It's been deemed necessary by many to restrict PHP's read/write access more so than Perl's. As such, the benefit is potentially unmeasurable -- no one wants to be the victim of lots of overwritten files or whatever might come of a security breach... Whether or not Perl is affected by those security issues does not relate to PHP's needs to be handcuffed, so to speak.
By the way, I'm on vacation in your own (and my place of birth) beautiful Vancouver this week and next. :)
Dan
I appreciate your willingness to make the change for future releases.
Quote:
I just find it shocking that under safe_mode, any files that php create, it can not read.Well, I'm not hear to claim it's the best solution, but it's the one the creators of PHP felt provides the best security and my sysAdmin (who's background is in network security probing) felt is necessary. Both parties know a lot more about the pertinent points to consider than I do, so I'm not here to second guess them...
Quote:
This really limits a lot of applications that aren't database drivenAgreed. However, that's really neither here nor there... It means certain things are more challenging, but I view that as a necessary evil with my own programming if I don't want to limit the target audience.
Are there any flatfile PHP forum systems out there?
Quote:
and even us implementing an admin area for Links SQL! How is Links SQL going to build pages if the next time it tries and build pages it won't be able to overwrite the file!Are you looking into making the Perl admin area PHP based to match the PHP front end? I assume you're also considering ways of allowing static-built PHP pages? I could see that being quite difficult from a safe mode standpoint... One key difference there is that that is an option. I.e. users can choose to go static or dynamic, but static would not work for them if there server is running under safe mode. With the current compiled files discussion, there is no option of whether or not to use it, so it's important that it be made to work for everyone.
Quote:
This is really a poor setup choice by your ISP, as it really limits alot of the functionality in php for no benefit (as a user can get around the restriction using CGI).I don't really agree with that, as I think it's juxtaposing and confusing separate issues. Sure, CGI scripts can get around PHP's safe mode restrictions, but that has nothing to do with the matter of why PHP locks down such things. It's because of PHP's security considerations, not Perl's. It's been deemed necessary by many to restrict PHP's read/write access more so than Perl's. As such, the benefit is potentially unmeasurable -- no one wants to be the victim of lots of overwritten files or whatever might come of a security breach... Whether or not Perl is affected by those security issues does not relate to PHP's needs to be handcuffed, so to speak.
By the way, I'm on vacation in your own (and my place of birth) beautiful Vancouver this week and next. :)
Dan