Re: [PHP-DEV] safe_mode redesign
Hi Jason, I also have some ideas how to improve safe_mode: - Being able to limit the hosts/ports the socket/mysql/fopen/etc functions can connect to. I have seen a few cases where a PHP user used the socket calls to send spam to a mailserver. He/she deleted the script afterwards, and nobody was able to find out who sent the spam... - Extend the functionality of open_basedir. This could be used for the virtual-chroot / shared directories you mentioned. - I can imagine that the configuration files can become very large when you want different limits for different groups of users. So maybe a way to make 'shortcuts' for certain settings? For example something like: php_admin_varbasic_dirs/var/www/shared:...:...:... php_admin_vardb_users /var/www/db:/usr/local/php/:...:... php_admin_varpower_users $db_users:/var/www/power:... virtualhost 1 php_admin_value open_basedir $basic_dirs /virtualhost virtualhost 1 php_admin_value open_basedir $basic_dirs:$db_users /virtualhost virtualhost 1 php_admin_value open_basedir $basic_dirs:$power_users /virtualhost This could make managing a lot of virtual hosts very easy. Just some ideas. I don't know yet how many time I can set aside to help on implementing security features... Sander. - Original Message - From: "Jason Greene" [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Thursday, February 01, 2001 9:53 PM Subject: [PHP-DEV] safe_mode redesign Is anyone up for a discussion on the redesign of safe_mode? I would like to start working on this sometime soon, and I have a lot of ideas, but I know this is going to be something of a large debate. Some of the new features I think would benefit php include: * safe_mode_hide_env_vars - will allow extra protection on removing environmental vars from hosted users ( I actually have a patch for this but I have been waiting on it to discuss the redesign) * User configurable policy - safe_mode could have configuration directives to specify exactly what checks are desired * Virtual Chroot - the ability to perform a chroot to a virtual host directory structure, so that a hosted user can not access anything outside of their directory structure. * Shared Directories - The ability to specify a list of paths that are shared amongst all hosted users. This would allow certain extensions (gd, oracle, etc) the ability to access the needed datafiles without failing a safe_mode check. Any comments, suggestions, other ideas? -Jason -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Re: safe_mode redesign
Hi Zeev, -- Quoted from Zeev: The one main problem with safe_mode in general is that the idea is problematic by definition. Security outside the OS level is prone to errors, and a false sense of security is much worse than knowing you're insecure. I agree. I think this means that either: - We shouldn't do very much on security - We should make clear we are NOT providing complete security, but that we only try to help the administrator by giving him some extra options. In my opinion, safe mode should only feature features which can have an infrastructure-level solution, and are not prone to errors. There aren't too many of these. The current safe mode implementation is extremely prone to errors because it tries to protect opened files, and the way its built, it's bound to be missing checks in many places... I know :( Maybe we could make a document that describes what a module/extension should do to be considered 'safe-mode compatible'. That way it would be easier for the module author to check his code. I don't believe anyone is intentionaly writing 'insecure' code. Sander. -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Links to companies supporting / teaching PHP
Hi, To keep it short and simple: A related company is teaching PHP courses. Is there a place where things like this could be mentioned on the php.net site? Thanks, Sander Steffann Computel Standby BV / www.nederland.net / php.nederland.net -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4 /ext/standard basic_functions.c incomplete_class.c php_incomplete_class.h var.c /ext/wddx wddx.c
Hi, Deprecate dl()? I think it's one of the most useful functions... :) How so? I can understand that people get used to it, but it's really bad. extensions should be loaded in the php.ini file. There's really no good reason for using dl() over the php.ini method. I agree with you when we are talking about using PHP in a webserver. However, I am seeing more and more use of PHP as a generic scripting language. In this situation, I think dl() is very useful... Imagine a application written in PHP that has a 'special' extension. For example, an extension to access a scanner. You don't want this loaded everywhere, just in your scanner application, and certainly not in your webserver. In a few words: For a webserver: ban dl() For generic scripting: keep dl() Sander. -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Versioning (resent AGAIN due to lack of replies)
Hi, PHP_VERSION_NUM +1 from me too. Example: GD_EXT_VERSION = 30201 Very big +1 on this one (or something similar). What also would be useful is a built-in way to determine optional parts of extensions, like something to check if GD supports GIF/PNG/etc. This way, you can check the version and the optional parts. Sander. -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Versioning (resent AGAIN due to lack of replies)
Hi, Very big +1 on this one (or something similar). What also would be useful is a built-in way to determine optional parts of extensions, like something to check if GD supports GIF/PNG/etc. This way, you can check the version and the optional parts. You mean this: http://www.php.net/manual/en/function.imagetypes.php Yes, but in a generic way, so other extensions use it too. Sander. -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] [RFC] Versioning rules for PHP/Zend/PEAR/Extensions
I think the key still lies in creating a repository for C extensions where each extension can have its own release cycle. +1 one for this... :-) Sounds good. I think this would make it easier for the developers of the extensions AND the developers of the 'main' code. The drawback is that it could make it more difficult for someone to determine what he needs to run a certain script. But at the moment, a lot of people compile their own PHP with the extensions they need, so the problem already exists. When using a central repository it should work fine (I think ;) So that's a +1 from me too. Sander. -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Re: exit() / die()
I'm glad I read the list. Doing (a) will break several scripts that my site depends on. Ok, I was mistaken in thinking it wouldn't break (a lot of) existing code. Zeev Suraski [EMAIL PROTECTED] wrote in message news:5.1.0.14.2.20010929020430.051aa2a8@localhost... Guys, Changing these is quite out of the question - they've been a core part of the language since 1997 (at least), and have lots of lines of code that rely on them. Moreover, there's no clear-cut reason to change it, especially considering it only makes sense when used in command-line mode, whereas the current behavior is useful in all SAPIs (in order to introduce such a compatibility-breaking change, we need a *good* reason). You are right. I have been doing some command-line work lately, and I was surprised that exit() didn't do what I expected. But PHP is still (mostly) a web-server language, and there it would make no sense indeed. Changing my vote to -1 on changing and +1 on introducing a new function :) Sander. -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] PHP 5
Hi, Always building the CGI version would also help the PEAR command line installer a lot since it currently needs a PHP binary to be executed. Yes, I had that in mind. We should get /usr/bin/php on as many machines as possible. This message from Stig S. Bakken summarises nicely what I'm trying to say: http://marc.theaimsgroup.com/?l=php-devm=100313140811956w=2 Sounds very useful. I'm using PHP more and more instead of shellscripts, mostly because I am more familiar with it. +1 from me Sander. -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Re: PHP 5
Hi, We do exactly the same with Apache SetEnv: SetEnv media_regionaamapeldoorn SetEnv media_regioid 27 SetEnv media_module index And we get them in the PHP script with $GLOBALS['HTTP_SERVER_VARS']['media_regionaam']; Works great for us. Sander - Original Message - From: Zeev Suraski [EMAIL PROTECTED] To: Joe Webster [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Wednesday, January 02, 2002 11:40 PM Subject: Re: [PHP-DEV] Re: PHP 5 This could probably be done. It does sound helpful. Zeev At 00:29 03/01/2002, Joe Webster wrote: Yes it would have to be in every script in the vhost, location or directory directive. It could be a constant =) That would make my life easier. Thanks, -Joe Zeev Suraski [EMAIL PROTECTED] wrote in message 5.1.0.14.2.20020102234728.028651c0@localhost">news:5.1.0.14.2.20020102234728.028651c0@localhost... At 23:33 02/01/2002, Joe Webster wrote: I have something that I am currently dealing with: Using mod_perl with apache, you can put this in a apache directive (vhost, location, directory): PerlSetVar somevarname somevarval and that would pre-define somevarname equal to somevarval. We are trying to move completely to php (we're 1/2 php and 1/2 perl) however, we really need to be able to set the vars like this. I did look through the mod_php.c and I noticed the php_value, php_flag, php_admin_value, and php_admin_flag, but nothing for a variable. Would it be defined in every PHP script that runs? Does it really have to be a variable, or can it be a constant? Zeev -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] FOSDEM 2002
Hi, Sterling and I will have a session there, it's just not updated on the site I guess. Any idea when your session will be? Sander. -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] [Fwd: Re: [Zend Engine 2] Case sensitivity: Conclusion(?)]
Hi, IMHO making PHP case sensitive after being case-INsensitive for so many years is a very bad idea. The reasons are already mentioned on the list. For us (ISP in The Netherlands) the most important one is BC. We would not be able to upgrade any of our servers when this would go into PHP5. A lot of our customers use PHP, and I think almost every customer would have scripts that break. (which is not acceptable ofcouse) Please don't do this... (That's a -1 from me) Sander. -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [Fwd: Re: [Zend Engine 2] Case sensitivity: Conclus ion(?)]
Hi, Even with the whole new object API, most of the code would work without modifications (at least mostly all of the PHP object code I got to take a look at). And if it doesn't - turning on PHP 4 compatibility should bridge the gap... Glad to hear that :) I have been thinking, and breaking BC _could_ be acceptable for us, but only if it is possible to run PHP4 and PHP5 side-by-side in one apache server... (Breaking BC with making everything case sensitive would introduce a nice possibility to clean up a lot of other things that were never doen to maintain BC though, but lets stick to this point for now :) Sander. -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Nostalgia
Please stop discussing people, and start discussing PHP. Be mature enough to let this rest. This discussion will lead nowhere. Thanks ;) Sander. -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] cvs: ext/baby
Hi Rasmus/Christine, -1,2 +1,6 Christine Lerdorf Rasmus Lerdorf +Buster (working name only) Lerdorf +Born 13:26 PDT Wednesday March 6, 2002 +Weight: 9.0 pounds +Length: 19.25 inches Congratulations! Sander. -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Let's fork GD!
Hi, Well, as far as I understand it, simply reading an LZW compressed GIF would not violate the license. It is software that creates LZW-compressed GIF files that need to pay up. So, we could still support GIF and manipulate LZW-compressed files, but once we read it in and manipulate it, we would not be able to write out an LZW-compressed GIF. That means the GIF files created by PHP-GD would be much larger. Which is not a problem IMHO. Like said before, GIF should go away. The only reason to support GIF (for me at least) is to make it possible to migrate to other formats gradually, without breaking existing scripts. We still have users who use GIF output, and it would be nicer to say to them: migrate to PNG because it is more efficient, than: migrate to PNG *NOW* otherwise your site won't work anymore... Oh, yes, and a +1 from me on integrating GD! Sander. -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] ?= and %= both work, why not ?php=
Hi,
From: http://www.w3.org/TR/2000/REC-xml-20001006#sec-pi
[16] PI ::='?' PITarget (S (Char* - (Char* '?' Char*)))? '?'
[17] PITarget ::=Name - (('X' | 'x') ('M' | 'm') ('L' | 'l'))
[3] S::=(#x20 | #x9 | #xD | #xA)+
[2] Char ::=#x9 | #xA | #xD | [#x20-#xD7FF] | [#xE000-#xFFFD] |
[#x1-#x10]
Meaning that between ?php and ? everytning is allowed but '?'.
Nice to know! Not that it matters to the ?php= discussion, because if
someone doesn't want to make a valid XML document he has plenty ways of
doing that...
About the ?php= thing: IMHO it can be put in, because the people who don't
like it just won't use it... I understand that others want to keep the
language clean, which is very important too! I probably wouldn't use it, but
I have nothing against it either.
But: very nice to know the XML thing. Thanks!
Sander.
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP's vision
Hi, And doesn't ZE2 address almost all of those OO related things? It does. Personally, I'm missing two things in Zend Engine 2.0: interfaces and private methods. Both are not really critical, as they don't aim at solving technical problems, but social ones during the design process. Private methods would be very nice to have. Like you said, technically it doesn't matter, but it makes it easier to 'educate' people. Example: I have written some classes for my company, and I made docs that explained all the available methods. Now a co-worker had a look at the sources, and decided that a few 'internal/undocumented' functions were useful to him... Since I didn't know those functions were used outside the class, I changed them and broke some of his code. The obvious sollution would be to educate my co-worker about using undocumented features, but doing this through programming language constructs makes this a lot easier (and I can be SURE nobody uses that code where they shouldn't). Just my personal reasons why I would like private methods :) Sander. -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] oo != php
OO IS OO... JUST BECAUSE JAVA IS OO DOESN'T MEAN WE ARE SUGGESTING MAKING JAVA AGAIN. WE ARE SUGGESTING MORE OO FEATURES. Please Pleas Please realize the difference. Im sick of people associating oo features as java features! Making php more like java would be suggesting making a public static void main(String args[]) in a class, and that gets run when a class with that name is loaded. Now this is stuff specfic to java! Not MI or public/private members these features have been around way before java was ever thought of!!! I completely agree here. Having some extra OO features would be nice. There are a few conditions: - Using them must be optional - Performance should not suffer too much - A clean implementation is possible If adding a few OO features for the people who want (or even need) them can be done under these conditions, I think it should be considered seriously... If one of these conditions can not be met for a certain feature, it won't be worth adding IMHO. Sander. -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Error in zend2_example.phps
I think zend2_example.phps has a little error in example 6:
The display function is defined as:
function display()
{
print $this-name;
print \n;
}
But then it is called with:
print $person-getName()-display();
Either the function should use return, or the call shouldn't use print...
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] auto_prepend/append: does the PHP engine cache the
Hi, What about setting server variables? You can set them once, they stay in memory and your scripts can read them. Just an idea... Hum ... very interesting! I have no idea how to set Apache server vars but I'll definitely look into it! We do the following in our Apache virtual hosts: VirtualHost * ServerName www.example.com DocumentRoot/var/www/www.example.com/ SetEnv cityapeldoorn SetEnv region_id 97 SetEnv module_name index /VirtualHost You can then access these from PHP: ?php echo $_SERVER['city']; ? Good luck, Sander. -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Forked ext/gd by default
Hi, I think we should use forked version of gd library by default for 4.3.0. From what I hear it is already the best version of any of them out there and if it saves us any more grief, all the better. Objections? Sounds wonderful! +1 from me. Sander. -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] ODBTP, a possible solution for MS-SQL and other databases
Hi, To php-dev: I feel that Robert has had a bit of a cool reception; opensource development relies on positive feedback to make progress. Sorry that I'm late :) I too think this is a very nice extension!!! We (nederland.net, hosting provider in The Netherlands) don't need this yet, but I expect that in the future we will have customers asking for something like this... I expect this extension will be very valueable for a lot of PHP users. Keep up the good work! Sander -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 4.3.0 released
Hi All, There is a weird line in here too: * PHP Manual: Using PHP from the command line http://www.php.net/manual/en/features.commandline.php It's this one: By default when executing make, both the CGI and CLI are built and placed as sapi/cgi/php and sapi/cgi/php respectfully The second path is wrong, and respectfully should be respectively. But I'm glad the CLI is 'official' now! :) Sander. -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RfC: version names
Hi, So what happens if I do this? cd php4 cvs upd and a day later do this? cd php4/ext/standard cvs upd What is the checkout date here? I've no idea, do you? I think we just should not allow submissions with test results if they're not made by a snapshot or our phport.sh thingy for automatic testing. Sounds a lot more reliable :) Sander -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
