Joomla and Windows file permissions - Explanation

Joomla and Windows file permissions - Explanation

Written by Russell Winter

 

For those of you that are either developing or delivering your Joomla! Web-Sites from the Windows environment, it is sometimes difficult to obtain relevant information regarding permissions. Unfortunately, it is a fact that most Web-Serving is offered under Unix and that Unix is pretty well documented within this environment. Hopefully the following information will go some way to clearing up any confusion and provide a little guidance.

Windows Web-Servers Overview
Firstly, lets discuss the differences between servers, in general most Windows folks appear to be using either Apache(Win32) or Microsoft IIS, these two servers operate very differently and utilize slightly different models of delivery.

Apache(Win32) generally runs on the host computer as the User that it was installed under, whereas IIS installs under a specific user but will run under a newly installed user " IUSR_ ".

Permission Defaults
By default, Unix tends to only give full access to the "owning" user to files and directories, in opposition to this approach Windows by default will also assign the Group "Everyone", Full permissions. The first thing any good Windows Administrator does is remove the rights of the "Everyone" group, to improve security. For local PC testing, this is probably not necessary, but explains why, if "Everyone" is not removed and you run some form of permissions check script or the Joomla! Pre-Installation check, on the whole you will have Full "Read, Write and Execute" permissions, because you are aquiring the rights of the "Everyone" Group.

Microsoft Internet Information Server (IIS)
IIS comes in two main flavours, PWS (Personal WebServer), and IIS (Internet Information Server). Essentially these are the same application, PWS is just a cut-down version of IIS designed for desktop environments, whereas IIS is designed for Server environments. PWS limits you to a single main site, so your application installations will generally be in sub-directories of the main site. IIS, on the other hand, provides the functionality for Virtual Hosts to be run from these directories, delivering multi- site capability.

Due to the different functionality limitations, PWS does not have the "Permisisons Wizard" as it is determined to not be needed, only one user will be using the Server, but in IIS many users will be using the Server, thus differing permission assignments are needed.

Once the "Everyone" account is removed, Windows IIS is now left with the " IUSR_* " account having top-level rights to the Web-Server directories, a pemrisisons check now should yield different results. Only the IUSR_* account has full permissions and other users shuld acquire eihter "Read Only" or no rights. Read only rights are determined by which other users have been assigned what rights to the IIS directories manually.

Assigning Permissions
Assigning permissions in Windows is reasonably straight forward, but can be a little confusing at times.
Right-Click on the appropriate folder or file, selecting "Properties" or "Sharing and Security" will enter the Windows Security Management pane. Selecting (cick once) on any user name listed will display the rights that user has (in the bottom half of the pane), some rights might be "greyed" out, these are unavilable, either because the current user (you are logged in as) does not have higher enough pemrissions to alter them, or they are inherited from the directory above and have been set to use that higher level directories pemrissions (this is generally the default mechanism).

As you can see, Windows utilises the following Pemrissions/Rights scheme;

1. 

Full Control

Allows: 1, 2, 3, 4, 5, 6, 7

 2.

 Modify

Allows: 2, 3, 4, 5, 6

 3.

 Read & Execute

Allows: 3, 4 

 4.

 List Folder Contents

Allows: 4 (but connot run programs) 

 5.

 Read

Allows: 5 (Implies: 4)

 6.

 Write

Allows: 6 (Implies:4 )

7.

 Special Permissions

Allows: Combinations 

 

Windows file permissions can be seen as having ^similar properties as UNIX or Linux file (Modes) permissions they are just represented differently.
For example, you are probably used to having permissions represented as 644/666 755/777, instead of being described in the terms above. So, when you are quoted to use 644 this equates to:


   The owner of this file can read and write to it.
   The owner's group can read the file.
   Everyone else can read the file.

^ Windows and Unix permissions (Access Control Lists) do not equate exactly, as Windows does not use "Groups" mechanism in the same manner, but for this discussion and in regards to the Web-Hosting environment they can be summarily equated.

 

Ah but,  in windows "Groups" are not used and "Everyone" should have been removed.....

So this is where Windows and Unix do not quite equate, but what can be done is to "match" or "correlate" equivalent meanings. So this outline is not really going to provide you with a Windows or an NTFS specific permissions guide but more of an understanding of how the commonly quoted numbered UNIX/Linux style permissions correlate on a machine with an NTFS file system.

 
The files that are placed in the www or public_html root folder, or whatever directory your site (www.domain.com.au or localhost) points to on your hard drive should be owned by your user account, but only if that user is not what i sconsidered as a privileged user like "Administrator" on Windows or "root" on UNIX/Linux. These accounts should not be used for everyday use.


Commonly used security practices suggest that all FILES should have the following permissions.

       Owner  :  Read & Write

       Group   :  Read Only

       Others : Read Only


    all DIRECTORIES/FOLDERS should have the following permissions.

       Owner  : Read, Write & Execute

       Group   : Read & Execute

       Others : Read & Execute


Arguably, this is not necessarily "optimum" security, but a balance must be struck between security, functionality and maintainability.

Windows, unlike Unix, does not maintain a single ACL for "Execute", but simply provides "Read & Execute" combined, which does not imply "Write". The "Read & Execute" ACL does however also implies "List Directory Contents". Therefore, if you have only Read & Write permissions on a directory but no "Execute" you will not be able to see the contents of the directory and may also have problems when attempting you run the file through a Web-Browser.


Unfortunately a little understanding of UNIX/Linux permissions is required to fully equate/corrolate in to Windows permisiosns, the following "cheat-sheet" should assist;

 

Unix Mode

Windows ACL 

Comments 

 Modify 

Read, Write & Execute, you should be the owner of this file

6

 Read & Write

 

5

 Read & Execute

used for most applications

4

 Read Only

security through obscurity is not a good practice

3

 Write & Execute

not available through windows, unless "Special" Permissions is used, not commonly used

2

 Write Only

not available through windows, unless "Special" Permissions is used, not commonly used

1

 Execute Only

(not available through windows, unless "Special" Permissions is used, not commonly used)


So as a comparison example to Unix Modes, when you are quoted something like 644, you would now need to break that in to three entities;      6  :  4  : 4

The first number represents the "Owners" permissions, the second represents the "Group" permissions and the third, the "Other" permissions.


So the Windows equivalent would be something like;

  Owner (6) : Read & Write

  Group (4) : Read Only

  Others(4) : Read Only

 

Hopefully, this example provides some insight in to the how to correlate Unix Modes/Permissions in to Windows Permissions/ACL's. this document does not include more complex subjects such as "effective". "Inherited" or "Special" permissions, despite Windows ease of use, Microsofts' Permissions and ACL's mechanisms are actually reasonably complex and very extensive, but this might just give you a quick reference to try and eleviate some of the confusion surrounding Unix and Windows Permissions translations.

XYZulu Hosting Blog

  • Are you tired of wasting time troubleshooting web hosting issues? Do you often find it frustrating to gain access to and/or register domain names for your customers? Why do you need us? With years of experience in the web hosting industry, we are in the perfect position to provide support to you and your clients. … Continue reading "Web developers, we want to work with you"

  • Web designers, we want to support your growing business. You don’t need to keep up with the ever changing web hosting industry, let us do it for you. We look forward to giving you the personalised support you need. Contact us today! “Collaboration divides the task and multiplies the success”

  • Imagine you have had a great new website developed. What can you do to ensure it stays up and running, is not compromised/hacked and continues to keep showing up in Google and other search engines? Here are 3 simple tips: 1. Keep software and components/plugins up to date Your website most likely runs on some software, … Continue reading "3 Ways to keep your website working"

  • XYZulu take security very seriously and we want you to do same. We are pleased to announce that 2 factor authentication (2FA) is now available to all our valued clients. To activate two factor authentication, please visit our support article: Enabling two factor authentication (2FA) for your XYZulu Customer Portal login What is 2FA? Please read this post: Why do I … Continue reading "2 Factor Authentication now available for all our clients"

  • Do you have a mobile phone or mobile device? If so, this post is for you. We often don’t stop to think about the important role our mobile security plays in protecting our digital assets. But just think about what issues you might face if your mobile was stolen and the thief was able to … Continue reading "3 mobile security tips"