• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 238
  • Last Modified:

File Browser Problems

I'm using a text editor for my custom CMS.  I can't seem to get it to work without modifying permissions on my server.  Shouldn't this just work without modifying permissions?  PHP is able to read and write stuff, and this uses PHP...

http://docs.fckeditor.net/FCKeditor_2.x/Developers_Guide/Server_Side_Integration
0
rowejd
Asked:
rowejd
  • 4
  • 3
1 Solution
 
torimarCommented:
Depending on how you upload files to your server or install applications on it, files and folders may have very different owners, like ftpuser, root, nobody etc.
On top of that, there is the ownership of the apache process.

Modifying permissions is a common procedure here in order to make sure that your application can write and execute in the required way. I should not be bothered about it - unless, of course, I did not get your point.
0
 
rowejdAuthor Commented:
I spoke with a tech support rep earlier who didn't know what he's talking about, so maybe you can clear it up.

I think the FCK Editor requires that php/apache (user nobody) be assigned write permissions.  I asked him to do this on my reseller account.  He said this is possible on a dedicated server but not on a reseller account.  I told him that previously, on the dedicated server, they set user nobody with read-write permissions so that FCK Editor could work with its integrated file browsing capabilities.

He said that setting chmod to 755 or 777 is the exact same thing as allowing user nobody read/write (doesn't make sense to me).  But he also said that setting user nobody with read/write permissions is VERY insecure and would allow any script access to the server.  And that because they're using PHPSusex with the shared servers, this isn't possible.  Could you please shed some light on this, since this guy just talks in circles?
0
 
rowejdAuthor Commented:
In case it helps...here's a snippet of what they used to make FCK Editor work on my dedicated server.  Is this insecure?  Any reason this type of thing couldn't also be done on my reseller account with a shared server setup?
[root@server1 public_html]# ls -al
total 92
drwxrwx--- 17 nobody nobody 4096 Jan 21 11:47 .
drwx--x--x 21 gawiless gawiless 4096 Jan 23 16:44 ..
drwxr-xr-x 2 nobody nobody 4096 May 1 2007 cgi-bin
drwxr-xr-x 2 nobody nobody 4096 May 5 2007 contractors
-rw-r--r-- 1 gawiless gawiless 0 May 4 2007 .htaccess
drwxr-xr-x 3 nobody nobody 4096 Jan 15 13:29 images
drwxr-xr-x 3 nobody nobody 4096 Jan 8 01:01 includes
-rw-r--r-- 1 nobody nobody 6492 May 7 2007 index.php
drwxr-xr-x 14 nobody nobody 4096 Jan 22 09:38 new
drwxr-xr-x 6 nobody nobody 4096 May 5 2007 pdf
drwxr-xr-x 2 nobody nobody 4096 Jan 5 01:01 private
-rw-r--r-- 1 nobody nobody 260 May 4 2007 robots.txt
drwxr-xr-x 2 nobody nobody 4096 Jul 8 2007 Scripts
drwxr-xr-x 9 nobody nobody 4096 Sep 29 01:01 secure
-rw-r--r-- 1 nobody nobody 2829 May 7 2007 sitemap.php
-rw-r--r-- 1 nobody nobody 769 May 7 2007 sitemap.txt
-rw-r--r-- 1 nobody nobody 857 May 4 2007 styles.css
drwxr-xr-x 2 nobody nobody 4096 Jan 8 01:01 Templates
drwxr-xr-x 3 nobody nobody 4096 Jan 8 01:01 uploads
drwxr-xr-x 3 nobody nobody 4096 Jan 21 11:47 userfiles

Open in new window

0
Free learning courses: Active Directory Deep Dive

Get a firm grasp on your IT environment when you learn Active Directory best practices with Veeam! Watch all, or choose any amount, of this three-part webinar series to improve your skills. From the basics to virtualization and backup, we got you covered.

 
torimarCommented:
To be honest, I think that the tech support person was right.

As long as you are required to adjust permissions yourself via chmod 755 and 777, you still maintain some sort of control over which files and folders should be accessible/executable. But as soon as you grant generell permissions to user 'nobody' (who most likely is the owner of the apache process), every malicious script unknowingly started within the apache context by you, a co-admin or maybe even a privileged user, potentially will be able to execute. That is indeed a risk.

All PHP built applications that I have ever installed on my server came with instructions on which permissions to change for them to run. I never considered this a big deal, and I certainly shouldn't want to change it by granting overall permissions to 'nobody'.

Even if this has run fine so far on your dedicated server, it seems to me to be more vulnerable to possible exploits.
0
 
rowejdAuthor Commented:
Well, I looked into a different text editor -- TinyMCE.  But it seems it needs to do the same thing.

I'm sorry for my ignorance.  But here is what it says:

Setting write access

You need to make sure that the specified filesystem.rootpath is writable by PHP and Apache, this can normally be done using a FTP client or a SSH shell. Remember if you are using safe mode the user and group must also match not only the access rights.


======
So if apache is user nobody...then how do they, FCK Editor, and ANY editor like that that includes a file browser extension...how can any of them be secure?  Tons of folks use them.
0
 
torimarCommented:
I have been reading around a bit, and it seems that even the professionals aren't quite conformous as regards Apache and user Nobody.

Whereas some web resources and also the popular "Linux Administration Beginner's Guide" claim that after root has setup and configured Apache the service will be run by a lower privilege user, by default 'nobody', the "Apache Definitive Guide" makes user 'webuser' from 'webgroup' the standard owner of Apache. Even more contradicting, the "Linux Bible" in two consecutive editions plus some other web resources state that user 'nobody' is the default guest account, and that only remotely connecting users will be members of the group 'nobody'.

In either way, I still think that giving user 'nobody' the ownership of your public_html is a very insecure way of solving the permission problem.

Now returning to your questions:
On your dedicated server you could do this, because "chown" needs to be run by root, and you were the root user. On a shared hosting space, you cannot do this because you don't have the permission to run "chown". But you, as the owner of the files you uploaded and folders you created, can still use "chmod" (via telnet or ftp client) to grant read/write access to others.

"755" means that everybody (including 'nobody', of course) can read and execute a file, but only you, the owner, may write to it. "777" means that everybody (including 'nobody') may read, write and execute a file. Most scripts will require 755 in order to run properly, others may demand 777.

Not only when setting up an editor, like you do, will webmasters have to adjust these permissions, but also when installing most CMS and forum software, blogs, wikis, galleries etc

Of course, there is an inherent risk in 777. In order to tighten security here, providers use tools like PHPsuexec, which will allow all scripts to run in 755 mode.

Here is a link that explains how PHPsuexec works (it's from the tutorial of a CMS which also uses one of the editors you were talking about):
http://www.joomlatutorials.com/faq/view/joomla_security_tips/permissions_under_phpsuexec/60.html

And here's good and concise intro to Linux permissions:
http://www.zzee.com/solutions/linux-permissions.shtml
0
 
rowejdAuthor Commented:
thanks
0

Featured Post

Free Tool: ZipGrep

ZipGrep is a utility that can list and search zip (.war, .ear, .jar, etc) archives for text patterns, without the need to extract the archive's contents.

One of a set of tools we're offering as a way to say thank you for being a part of the community.

  • 4
  • 3
Tackle projects and never again get stuck behind a technical roadblock.
Join Now