Page 4 of 4
Posted: Sun May 23, 2004 10:32 am
by launchcode
Possibly - I don't know what kind of hosting deal you've got. One way I did it was to have two versions of PHP - the standard "nobody/apache" version which ran the main site (and was configured to handle .php files) - and a CGI version running as my own user account, configured to handle .phpu files. Then I just swapped between the two if the user needed to upload files.
Posted: Sun May 23, 2004 11:11 am
by McGruff
mjseaden wrote:Hi McGruff,
I could do this, but I wouldn't really be able to manually change permissions each time a file is uploaded. I am not the only one uploading files, rather remote users with a username and password given by myself will also be able to, therefore it needs to be fully automated otherwise it creates unnecessary work.
OK. I may have missed something but here goes.
You want to move files to a new directory using a php script. This directory's parent folder is owned by something other than php.
1. CHMOD the parent folder to 777 (with your ftp program)
2. create all the folders and sub folders you will need with a php script; all these new dir's will be owned by php - apache/apache owner/group I think it was in your case
3. CHMOD the parent folder back to 755
Php file writing fns can now be used in the new folders. You don't have to CHMOD the parent folder open to 777 each time - just once when you first set up the filesystem.
Your FTP program will not have write permission in the new folders, at least not unless they have 777 permissions (which of course they shouldn't).
Posted: Sun May 23, 2004 4:49 pm
by mjseaden
Hi McGruff
Thanks for your help. Unfortunately, the filesystem works in such a way that for each upload, a random directory is created to upload into. However, creating a new directory is not necessary, I could equally get rid of the creating-directory part and just park them all in the upload folder before deleting using the same PHP script. That would work, right?
Posted: Sun May 23, 2004 4:58 pm
by mjseaden
Additionally two things
(1) Why when I try to use chown( <filename>, 'myusername' ) to claim the file as mine using the same PHP script do I get a permissions error? Surely this same PHP script owns the file (this was touched on earlier but I didn't quite get it)
(2) I'm using uniqid(rand()) to generate random prefixes to upload the files for each user. This is done so that different users trying to upload files to the server at the same time do not overwrite each other in the same directory. What is the probability of uniqid(rand()) being the same on two computers at the same time? Virtually negligible?
Many thanks
Mark
Posted: Sun May 23, 2004 5:12 pm
by mjseaden
Additionally McGruff, the directory that the (image) files are moved into after physical resize by GD is also created using the PHP script, whose parent directory was created using FTP.
Should I delete the parent folder, then recreate it using PHP? Would this then solve the problem? What CHMOD should I use?
Many thanks
Mark
Posted: Mon May 24, 2004 9:09 am
by McGruff
mjseaden wrote:Additionally two things
(1) Why when I try to use chown( <filename>, 'myusername' ) to claim the file as mine using the same PHP script do I get a permissions error? Surely this same PHP script owns the file (this was touched on earlier but I didn't quite get it)
From the manual, "only the superuser can change the owner of a file".
mjseaden wrote:
(2) I'm using uniqid(rand()) to generate random prefixes to upload the files for each user. This is done so that different users trying to upload files to the server at the same time do not overwrite each other in the same directory. What is the probability of uniqid(rand()) being the same on two computers at the same time? Virtually negligible?
I don't know exactly, but very, very small.
mjseaden wrote:
Additionally McGruff, the directory that the (image) files are moved into after physical resize by GD is also created using the PHP script, whose parent directory was created using FTP.
Should I delete the parent folder, then recreate it using PHP? Would this then solve the problem? What CHMOD should I use?
Yes, if I've understood you correctly. Delete with ftp program, make dir with php and with permissions 0755. Php owns the dir, so can write any files / folders there.
The new
Wiki has a short piece on permissions & UID's.
http://www.apache.org/ might also provide some background info.
I know exactly how frustrating this all is. Hope it does the trick.
Not able to delete files from my own server!
Posted: Fri Jun 11, 2004 3:25 pm
by rfbaptista
Geez, I'm extremely disappointed now.
All the php gurus and years of work done on the PHP product/project and no one has bothered to modify the way that PHP creates files?
That's deplorable.
I, too, cannot delete the files created by PHP. I'm running on a Linux box, PHP 4.3.x. I have several websites on these Ace-Host.net servers. The first one I was on was running in some sort of superuser mode, and I could create, update, delete files from inside scripts and could do it using a variety of FTP and shell tools, too. So, being used to having NORMAL file control, when I started on a new website for another customer, I was making log files, session files, etc. all over. Then, when I moved the files to the new domain on another server, all of a sudden I couldn't write to a file I had just created. I tried chmods and that didn't work, so I started setting the umask to 011 prior to file access and was able to create/update files. When I tried to remove one, I noticed that the user/group was 99, "nobody". I contacted the server tech support and was informed about the other server running in an exec mode and this one wasn't. They then changed the owner and group to my login, AND I STILL CANNOT DELETE THEM! There is some sort of sticky problem that doesn't allow me to delete files that I own!
I also tried those snippets of code in this thread to unlink the files and directories, and guess what guys, they don't work for s... either.
This is such a major bug in the PHP language that I would have assumed it would have been addressed years ago. I asked the server hosts if they would either set up an "rm" or "unlink" script that would allow me to delete any NOBODY files under my own domain, or create a wrapper to execute my scripts under my own login and they refused both.
So, now it becomes the burden of the writers of the PHP core software to come up with a fix for this problem. There is absolutely nothing that can be done as a simple user, even when the files are chown'ed to me by the server webmaster. So I dare someone to come up with a fix that works for all php users, platform independent! It appears that Linux users are getting the wrong end of the stick on any of the fixes that might work under other platforms so maybe the linux problem should be addressed first.
I had such high hopes for what I was going to achieve on this website I am creating. If I cannot delete files, then I will soon use up my 2 GB of disk space and be out of business. Right now I have created the files I'm using from my own login and simply update them to zero contents occasionally, but who wants that kind of high maintenance website?
Rob

Posted: Fri Jun 11, 2004 8:00 pm
by andre_c
I don't believe it to be a php bug at all, but the way that the hosting companies set up the webserver. I haven't had any of those problems creating or deleting files when I set up my own server, or the server is set up correctly at the hosting company.
IMO to be able to add or delete or modify any file on a machine regardless of who created it, is not "NORMAL" file control.
Not able to delete files from my own server!
Posted: Sun Jun 13, 2004 1:00 pm
by rfbaptista
Andre
you missed my point on that. I said "under my own domain". If there is anything under my domain, which for legal purposes is my property, I should be able to have absolute control under what is there and what I want to delete. That is why I had mentioned a wrapper on the commands that would limit delete control to my domain only, and also be restricted to the NOBODY files. I'd say that was fair.
Rob
PS, if it's not a bug, it sure is one heck of an inconvenience. For yourself, setting up your own server, I would expect you to have set it up so it worked properly for yourself. Being that this is a common server used by several hundred domains hosted on one machine, it is not set up to run under my own name and permissions. Therefore, it seems logical that there would have been a command that was fopen("filepath", "openmode", "create using domain owner's name & group flag");
Posted: Sun Jun 13, 2004 2:41 pm
by launchcode
rfbaptista - Why is it a BUG that your web host cannot correctly configure their server for your needs? That is the ONLY issue here - PHP has nothing to do with this, it can only work in the environment in which it has been placed, namely the web server. If that is restricted like this in the first place there is nothing PHP can or should do about it.
Get yourself a decent web host and stop trying to pass the blame to the language itself, you obviously know nothing about Unix security or the way Unix servers work.
Posted: Mon Jun 14, 2004 5:54 am
by rfbaptista
So replace "bug" with "problem". I put the post up there to encourage some of the smarter people out there to find a code fix for the "problem" if they can. Perhaps someone who was planning on writing a virus in order to get recognition for their abilities will instead take the challange to find a way to code around this file problem and be able to post it here and get recognition for themself.
I've been a programmer since 1978. I've been a PC admin since 1982 and a solaris admin for the last 10 years. I've programmed the Galileo satallite and spent 15 years writing radar identification for fighter aircraft.
If you want to be infantile and start trying to throw personal digs my way, and try to compare how *long* your SW knowledge is, then perhaps you should grow up before you reply again.
PHP installs on other unix type O/Ss sometimes have this problem, I've run on Windows without the problem, and have even run on another Linux server and not had the problem, but based on the postings I've read here and on other sites, linux installs seem to have more trouble and fixes that work for other users (outside of a programming change) do not always work on the linux boxes.
As I said before, grow up. I'm not blaming a language, and I do know quite a bit about unix systems since Motorola System V. You are responding to my posting as if you personally wrote the file I/O section in the PHP core and are personally offended that someone might find it less than optimum.
I have not said anything personal about your abilities to even understand the issue here. Apparently the entire message is above your head and like a small child you are lashing out with personal digs. I am not going to bother to respond to anything else you say because you are a baby who's just looking for something to argue about. If you do not have any information that may help solve the problem, why are you even responding in this thread?
In the past 26 years I've programmed on 20 different O/Ss, including those that I have written for embedded systems, using assembly language, microcode, basic, fortran, pascal, c, c++, Ada, etc. and CGI scripting languages such as TCL, shell scripts, Perl, Python, JSP, Java Servlets, Java Beans, Shtml, PL/SQL/Java store procedures, etc. "NORMAL" behavior with all those languages/OSs is that files created by a user are always owned and configurable by the user who is running the software. Therefore, anything that does not exhibit that behavior is the item that is outside the "NORM".
Posted: Mon Jun 14, 2004 6:30 am
by redmonkey
Any CGI scripting language I have used (admitidly not that many (mainly perl)) on Linux with Apache in a 'virtual host' environment, has required suexec in order to operate with the correct permissions.
In general, apache (or any webserver) on Linux will run as a user with limited permissions (usally 'nobody' or 'wwwrun' or something like that). When Apache runs any of your scripts which create files or directories these files or directories will be created by the user of which apache runs.
If you have access to the chmod, chown commands then you can use these to reassign ownership or set appropriate permissions accordingly. If not then only a script running under the Apache user will ba able to delete/unlink the created files and directories.
By installing PHP as a CGI you can configure Apache with suexec to execute your PHP scripts under your username. There is also (although I've never used it) suPHP which is meant to do the same thing specifically for PHP.
I don't consider this a bug or even a problem. It is simply down to how Linux works with file permissions. If you can understand it or think it's wrong, you should stick to Windose servers.
Posted: Mon Jun 14, 2004 12:11 pm
by launchcode
rfbaptista wrote:So replace "bug" with "problem". I put the post up there to encourage some of the smarter people out there to find a code fix for the "problem" if they can.
How can someone code around a SERVER configuration setting? If that is the way Apache has been configured to work on that server, that is the way it works - and there is nothing any single line of PHP code can do about it - and I hope to god that doesn't change, for the sanity of real sys admins everywhere.
If you want to be infantile and start trying to throw personal digs my way, and try to compare how *long* your SW knowledge is, then perhaps you should grow up before you reply again.
Well your fantastic knowledge isn't exactly helping out here, is it? It couldn't care less how long your coding schlong is, you clearly don't know the first thing about web server configuration/administration.
I've run on Windows without the problem
No? Really?! I wonder why that could be...
If you do not have any information that may help solve the problem, why are you even responding in this thread?
Because you're passing the buck and trying to blame this "problem" on something that doesn't even exist.
A misunderstanding of the way in which something works is not a bug.
"NORMAL" behavior with all those languages/OSs is that files created by a user are always owned and configurable by the user who is running the software. Therefore, anything that does not exhibit that behavior is the item that is outside the "NORM".
I agree 100% but you still don't get it, do you? YOU DON'T RUN AS A STANDARD USER WHEN VISITING A WEB SITE - you run as anonymous, nobody, yadda, zippo, nothing, the lowliest of the low and for all that is sane in the Unix security world - long may that remain. It doesn't matter if you use Linux, FreeBSD (my Unix of choice) or any other variant out there - unless you have configured your web server otherwise or are running a CGI build of PHP under a specific user account, this will always be the case.
It's as simple as that.
Frustrating, yes - but not difficult. You want to call me a "baby/infantile/etc" and challenge my skills because I think you have a problem with where you are placing the blame, then feel free - but this is basic Unix 101 and you obviously haven't graduated class yet.
Posted: Mon Jun 14, 2004 12:38 pm
by Weirdan
launchcode, rfbaptista
You're approaching the rink of flame war. Flamers ain't tolerated here. Stop while you can.
You're warned.
Posted: Mon Jun 14, 2004 1:22 pm
by launchcode
Fair enough, although we're well beyond the rink

Enough said on this topic anyway, it's a no brainer.