Hi, I'd like some help with a strange permissions problem I'm having. I'm working with PHP on two different host computers. One is running FreeBSD 4.0 and the other is a Cobalt RaQ 4 running Red Hat 2.2. Both are running Apache 3.1.12. The FreeBSD machine has PHP 3.0.14 and the RaQ has PHP 4.0.3pl1. I have some PHP scripts that work fine on the FreeBSD machine, but not on the RaQ. It's due to some strange permissions problems in how the systems are configured. Basically, I'm creating some subdirectories and files from within the scripts, then serving them to the user through the web browser. I notice that on the FreeBSD system, the directories and files that the PHP scripts create are owned by 'nobody' and belong to my own group (not a system group). On the RaQs, the files are owned by 'httpd' and belong to my own group. The RaQs set their umask to force the GID bit on everything created through telnet and otherwise, EXCEPT the things created by the PHP scripts CANNOT set the GID bit. I don't really understand why the RaQs make a standard practice of forcing GID perms on everything, as it seems like a hack for something else that didn't quite work out. The net effect is, on the FreeBSD system, I'm able to give 760 perms to EVERYTHING that the PHP scripts create and it all works just fine. On the RaQs, everything has 2777 perms or 777 perms and some of the files cannot be accessed by the browser (those owned by httpd without their GID bit set). Now, I'm no Unix wiz, but it seems really strange to me that you'd want the owner of everything created by PHP scripts to be the same as the Apache demon; it would appear that with very little effort, anybody would be able to write PHP scripts that muck with web server settings! I've seen this on two different RaQ systems, so I'd guess it's a default configuration of some kind. I really don't want to give world access rights to anything, and the RaQ won't even run my scripts unless they've got that level of exposure PLUS the GID perms. The FreeBSD system tells me it's not really necessary. Can anybody suggest how to deal with this? (Other than creating a bunch of shell scripts to accomplish what the PHP scripts cannot do.) -David Schwartz ps -- I'm not the admin of either machine. The RaQ's admin can't get that there's a problem.