SugarCRM Permissions 101

Of all the different problems associated with installing CGI scripts, many can be attributed to
incorrect permission settings on one file or another. Permissions are very important on a Unix
system because it prevents unauthorized people from viewing or editing files. Anyone using a
Unix system has an identity, and file and directory access depends on "who" you are.
Unix files and folders are protected on three different levels.
User
This permission value effects what the owner of the file can do to it. While it would be
fair to assume that only you as the owner would be affected by this setting - it may affect
a group of users depending on how your host has set up the server.
Group
These are usually the permission determining the rights of a group of users (usually
those using the same server as yourself) - these should generally be the same as the
owner's permissions because you are a user of the group when you are logged into the
server.
Other
This sets the permissions for anyone one else that may have access to the files but who
is not an owner or group. This setting will affect anyone who is trying to access the file
via the web, including the owner of the file (since the owner is only counted as the owner
when they are using the "shell" account or using FTP).

Understanding permission values

If you've ever downloaded a script and read the installation instructions you'll have likely been
told that you need to CHMOD a file to 666 or set the permissions to 755. So how does this set
of numbers relate to the various groups of the typical Unix file protection system? Well, there
are three numbers and three different types of permission...
• The first number relates to the permissions of the file owner
• The second relates to permissions for the group
• The third and last number relates to the permissions for any other type of user
So what do these numbers mean? There are three main reasons why a person may want to
open a file; to read from it, to write to it or to execute it (i.e. run it or use it). Each of these
properties has a value assigned to it, and it is the sum of these values that determines the
permission settings.
read write execute
permission
4 2 1
value

Once you know the permission settings for a file, you can determine exactly who is allowed to
do what to that particular file by doing some simple maths. Here is a table showing which file
attributes need to be set for all possible values of a setting.
 value read write execute So, following this table we can see that a file whose
0 no no no permissions are to be set at 755 will allow...
1 no no yes
• The owner of the file to read, write and execute (value 7)
2 no yes no • The group of the file to read and execute (value 5)
3 no yes yes • Other users to read and execute (value 5)

4 yes no no
In this case everyone has access to read the file and run the
5 yes no yes
program (assuming it was a script), but only the owner of the
6 yes yes no file can write to it (via FTP or shell access).
7 yes yes yes

Setting the File Permissions

So, now that you have an understanding of how to decipher the numbers used for expressing
file permissions - you need to be able to set them. There are two ways you can do this. Either
logging into your shell account and use the Unix CHMOD command, or using your FTP client
to do it for you. Since Unix shell accounts are only usually available to those power users that
pay for their hosting, FTP is the common method for doing this, as you do not have to know
about the Unix commands.
Here is an example of the permissions setting
interface of my favorite FTP client (leechftp). You
will notice that there are a total of 9 check boxes on
it, each acting as a toggle for switching the read,
write and execute permissions of each of the three
"groups" of Unix users.
To see this menu that allows you to set the
permissions, right click on the file or folder that you
want to set the permissions for and select the
CHMOD file option. This will bring up a menu
similar to the one shown here and in most
programs; it is just a case of checking the boxes that you want to set the permission for.

Notes about Permissions

You will notice that there is a note at the bottom of the example shown above. While there are
permission settings on Windows servers, they are usually only set at the server level and are
not comparable with the built in security features of a Unix file system - thus individual file
permissions can not be set by the owner via FTP on a Windows server. As for other file
systems, if they are Unix compatible then the chances are that the server will support the
CHMOD command, but the only way to be sure is to try and change the permissions of a file.
Another point to remember is that you are only considered the owner of a file when you
access it via a shell account or FTP (both of which require you to log in to be able to identify
yourself). If you are testing a script you have uploaded and you are using a browser to do it,
then you do not have the owner's privileges, rather the results of the script will depend on the
other user's permissions for the script and any files that are used for it. This is why it is
common to set a script's permissions to 755 (which allows other users to read and execute
the file) and its data-files to 666 (which allows them to read and write to the file)

OK All that said, heres what you do to secure your Apache/SugarCRM installation.

Step #1:
Configure your Firewall properly. This is a little too specific to your Linux distro to go
into here. I use SUSE which has a very easy to use Firewall configuration utility. Another
option is to get a Linksys router and put your server behind it, only opening port 80 (or 8080)
to your web server. There are FAQs on the Linksys website that tells you how to do this.
This step will protect you from about 90% of all security problems.
If you are using a hosted server then this step (hopefully) is taken care of for you. The
one problem with hosted servers is that your security is COMPLETELY dependent on how
good they set up the system and there is nothing you can do about it. The best thing you can
do is go with a reputable hosting company. Cheaper IS NOT better when it comes to
security.

Also disable 'Telnet'. Never, Never, Never use telnet. It is NOT secure. Use SSH
instead. SSH is loaded with just about every Linux distribution out there. A nice SSH client is
'Putty'. Just google 'Putty' and the second or third listing is the download page.

Step #2:
Secure the binaries, upload directory and the tmp directory.

First Secure Apache: (Your paths may vary)

chmod 511 /usr/sbin/httpd

chmod 750 /etc/httpd/conf/
chmod 750 /var/log/httpd/

All of these files and directories can be owned by the root user and the root group. I change the
logs directory's group to 'www' just because of my FTP users access. The '511' for the servers
executable may be a little restrictive but I like it. Of course, if you are using a hosting service you may
not have access to these files/directories. It depends if you are using a shared server or you have rented
one of your own. If security is important to you then renting your own box is the way to go, although I
have not heard of any of the major shared hosting services having any kind of security leak. They all
know that would be bad press.
 Second configure apache

Edit your httpd.conf and find the user and group settings

# User/Group: The name (or #number) of the user/group to run httpd as.
# . On SCO (ODT 3) use "User nouser" and "Group nogroup".
# . On HPUX you may not be able to use shared memory as nobody, and the
# suggested workaround is to create a user www and use that user.
# NOTE that some kernels refuse to setgid(Group) or semctl(IPC_SET)
# when the value of (unsigned)Group is above 60000;
# don't use Group "#-1" on these systems!
#
User www
Group www

OK, now make sure that the user 'www' and the group 'www' are created.

groupadd www
useradd www -g www -d /dev/null -s /sbin/nologin

The 'useradd' command allows you to create a user (www) that is attached to the
group 'www' and the '-s /sbin/nologin' part makes it so that a user could not login as www
from the shell or SSH/Telnet. Now there is a lot more security settings in your httpd.conf that
should be set and many are set by default. But the most important one is to make sure that
these directives are in your httpd.conf file. Your paths may vary.

<Directory />
Order Deny,Allow
Deny from all
</Directory>
<Directory /var/www/htdocs>
Order Allow,Deny
Allow from all
</Directory>

Again, if you are using a shared service then you will have to find out from your host
what user name and group your apache is running under. Once you have that information
you can proceed to the next section.
 Third Edit your php.ini file

Find your php.ini file and find this section and make it look like this. Remember that
your paths may vary:

;;;;;;;;;;;;;;;;
; File Uploads ;
;;;;;;;;;;;;;;;;

; Whether to allow HTTP file uploads.

file_uploads = On

; Temporary directory for HTTP uploaded files (will use system default if not
; specified).
upload_tmp_dir = "/usr/local/apache/uploads"

; Maximum allowed size for uploaded files.

upload_max_filesize = 22M

I like to put the uploads directory in the apache directory to make things easier to
debug. Also take this opportunity to change your upload_max_filesize.

Then find this section and make it look like this (your paths may vary):

; The file storage module creates files using mode 600 by default.
; You can change that by using
;
; session.save_path = "N;MODE;/path"
;
; where MODE is the octal representation of the mode. Note that this
; does not overwrite the process's umask.
session.save_path = "/usr/local/apache/tmp"

Again I like to have my tmp directory in the apache directory for ease of debugging.
Once you have finished these changes you will need to create those directories and then set
their permissions:

mkdir /usr/local/apache/uploads
chown www:www /usr/local/apache/uploads
chmod 744 /usr/local/apache/uploads
mkdir /usr/local/apache/tmp
chown www:www /usr/local/apache/tmp
chmod 744 /usr/local/apache/tmp

The standard “if you are using a shared or hosted server” disclaimer applies here as well.
Your upload and temp directory is already set for you and may be unchangeable.
Step #3:
Secure your SugarCRM Installation

The tightest security you could have in SugarCRM is basic to any

PHP application: the files must be owned by the Apache user, but that is
almost always impossible in the various hosted-environments I've
experienced. Ultimately, this means that the file/folder must be readable
by everyone (including the Apache user).
Chris Nojima – SugarCRM Software Engineer
OK, That being said, I say again that if security is important to you then a Hosted server may
not be. Best to rent a whole box rather than use a shared service. Better yet, own your hardware.
In my example your SugarCRM installation would be in /usr/local/apache/htdocs/CRM. So
what that as our path (yours may vary of course) heres what we will do:

chown -Rfv www:www /usr/local/apache/htdocs/CRM

chmod -Rfv 755 /usr/local/apache/htdocs/CRM

chmod -Rfv 775 cache (777 on a shared server)

chmod -Rfv 775 custom (777 on a shared server)
chmod -Rfv 775 data (777 on a shared server)
chmod -Rfv 775 modules (777 on a shared server)
chmod 774 config.php (777 on a shared server)

This makes the files in most of the installation Readable but not Writable, except in the
4 “Data” directories where I make them Read/Write by both owner and group (because my
FTP user is in the www group as well.

If you are using a hosted service then instead of 'www' you would use the user and
group that they would tell you. However, some Hosts will not allow you to change the owners
of the files, meaning that you have little choice but to use the old '777' trick.

Are these changes going to make you impregnable? No, especially if you are using a
shared server. But it will be pretty good. If you keep your software (OS, apache and PHP)
upgraded as recommended, use good and SECRET passwords you should be fine.
PHP_SAFE_MODE
Safe mode is used by hosts that don't want to do the work for themselves. It's the lazy
way out. It doesn't make a server more secure unless they turned off all other scripting
language. Since Perl doesn't have a safe_mode an attacker could write a perl script that
does what the PHP can't. Plus, even worse, it gives people the false sense of being secure
that leads to mistakes.

"the biggest problem with safe mode is that people use it".

Rasmus Lerdorf (the guy who founded PHP)

If your host uses it and refuses to do better then take your business elsewhere. If someone is
trusting the security of your site to php_safe_mode, then they don't really care about your
security. They are going the cheap and easy route and may not even know how-to secure a
server properly.