Need some assistance on news project

zenaphex

Edit: Rephrased message
I have made a simple news script that allows editing of a TXT file that is parsed by a java applet news scroller. It works great and all on Windows. Now I have moved it over to a Linux platform and there is permission issues. I tried using PHP's chmod() and chown() functions, shown in my example script below, but no luck. I keep getting, "Operation not permitted in...<some path name here>". The TXT file is originally set as read-only, but I would need to be able to set it as writable so I can update/edit the news file. Is there a safe approach to doing this without any possible exploitation? Here' the sample script I made so far to test out the chmod/chown stuff:

<?php
	chown("sample.txt", nobody);
	chmod("sample.txt", 0646);

$handle = fopen("sample.txt", "w+");

if (fwrite($handle, "A sample text file to test out chmod.")):
	echo "Sample.txt updated!";
else:
	echo "Error writing to file!\n";
endif;

fclose($handle);

chmod("sample.txt", 0644);
?>

Please help out as I don't have much security experience with Linux. Appreciate any help!

zenaphex

Something interesting I discovered. I created a new sample text file via a PHP script into the same directory for test purposes. What was insteresting is that the chown/chgrp id was "apache". The original text file was under different id's. It seems the "apache" id was the key to making it work even in chmod 644, unlike where I had to chmod 646 to write to it.

I still have to confirm this with the administrator for security reasons. Any thoughts/opinions on this would be helpful.

Please note that I am working behind a secure HTTP folder. So you have to pass authentication before being able to execute the script.

dalecosp

PHP runs under the same username/groupname as the web server unless you are using the CGI module (as opposed to, say mod_php for Apache) suexec()'ed to some other username.

The most common usernames for the apache web server are, in no particular order, www, apache, nobody, daemon. The group name likely corresponds...

The question, then, is how you moved it in the first place ("I moved it over to a Linux server...") I assume you used FTP. Since you were almost assuredly not logged in as "Apache", the other file has different ownership...that of your FTP login ...

You're probably in a bit of a difficult spot, unless your FTP user has permission to chown and chgrp to "apache:apache". It's pretty certain that PHP won't have permission to override your umask....

Of course, now I'm wondering if I answered your question at all...

You generally don't want to let PHP create files in a directory under the document root. If crackerz get in, they can then change the content on your site. Code as securely as possible ...

zenaphex

Yes, I am transfering my files via secure FTP. The FTP program I was using, "SmartFTP", seem to not have the ability to change the user/group id. I can view it, but not change it. I am not even sure if that is even doable via FTP.

I can create a new news.txt file in the sample secure HTTP folder the script resides in. So all this works behind secure HTTP. I did try to create the news.txt file in the root htdocs folder but that was unsuccessful. That's acceptable in a secure sense.

I don't think there's much I can do about someone beng able to view the HTML file that contains the applet properties which hold the location of the news.txt file. That's just a given and just something we all have to deal with.

Basically I have this news.txt file I want the client to be able to go in and edit/delete/add news entries without sacrificing security. Is there anything you or anyone else can reccomend for me to do?

If I did a secure login, should I use a different scripting language, for example PERL, or is PHP perfectly fine? And even though it's a simple news editing script, should I go with a SSL (or was it SSH? doh!) news editor?

Thanks for any information.

dalecosp

If you're going in via SSL (https://whatever.url) - I'd say that you're in pretty good shape. Just allow your scripts to create and maintain the text file.

The only worry, of course, is that this file could be viewed and perhaps changed by someone. If the path is outside the docroot, it's not an issue. If the scripts that write to it are secure, it's not much of an issue. I'd name it something a little unusual perhaps, but this seems fine. I have several sites that have a similar interface ...