LinuxQuestions.org
Share your knowledge at the LQ Wiki.
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Newbie
User Name
Password
Linux - Newbie This Linux forum is for members that are new to Linux.
Just starting out and have a question? If it is not in the man pages or the how-to's this is the place!

Notices


Reply
  Search this Thread
Old 01-16-2013, 10:57 AM   #1
misterpiddles
LQ Newbie
 
Registered: Nov 2012
Location: Boston-ish, MA, USA
Distribution: Debian
Posts: 17

Rep: Reputation: Disabled
A few questions, after reading Quick and Dirty Guide to File Permissions


This was an excellent guide and helped to clear up some file permission issues for me. I am clear on how setting absolute file permissions works with chmod with regard to the owner, group, and all others.

However, I had a couple of questions though regarding how permissions work on a live website.

Let's say we have a website with thousands of external users (not admins, or programmers, just the user-base). They will just be reading content and performing searches. No updates.

I'm assuming these users would fall under "everybody not an owner and group".

For setting file permissions for "all others" to just be able to view, should that permission be: r-- ?

Or do they even need the read permissions at all to view web pages, e.g. --- ?
 
Old 01-16-2013, 11:11 AM   #2
unSpawn
Moderator
 
Registered: May 2001
Posts: 29,332
Blog Entries: 55

Rep: Reputation: 3533Reputation: 3533Reputation: 3533Reputation: 3533Reputation: 3533Reputation: 3533Reputation: 3533Reputation: 3533Reputation: 3533Reputation: 3533Reputation: 3533
Quote:
Originally Posted by misterpiddles View Post
(..) live website. (..) a website with thousands of external users (not admins, or programmers, just the user-base). They will just be reading content and performing searches. No updates. I'm assuming these users would fall under "everybody not an owner and group".
Systems administrators and developers may require system access to modify or upload resources directly. Call it "real" access rights. To make it more interesting there may also be content editors who can edit pages. This often is done through a Content Management System (CMS). A CMS may allow fine-grained access, meaning an editor can only edit specific sections of a web site. Call that "virtual" access rights. Web site visitors do not require any such access: they just see whatever the web server allows them to see. If the web server can read something then it'll show them that something.
 
1 members found this post helpful.
Old 01-16-2013, 11:15 AM   #3
Habitual
LQ Addict
 
Registered: Jan 2011
Location: Youngstown, Ohio
Distribution: LM17.1/Xfce4.11.8
Posts: 7,668
Blog Entries: 10

Rep: Reputation: 2077Reputation: 2077Reputation: 2077Reputation: 2077Reputation: 2077Reputation: 2077Reputation: 2077Reputation: 2077Reputation: 2077Reputation: 2077Reputation: 2077
Quote:
This was an excellent guide and helped to clear up some file permission issues for me. ...
sorry if I missed it, but what guide is that exactly?

UnSpawn nailed it on the permissions overview.

n/m. told ya I 'missed' it.
http://www.linuxquestions.org/questi...issions-83986/ and/or http://www.linuxquestions.org/linux/...le_Permissions

Last edited by Habitual; 01-16-2013 at 11:17 AM.
 
Old 01-16-2013, 11:21 AM   #4
misterpiddles
LQ Newbie
 
Registered: Nov 2012
Location: Boston-ish, MA, USA
Distribution: Debian
Posts: 17

Original Poster
Rep: Reputation: Disabled
Quote:
Originally Posted by unSpawn View Post
Systems administrators and developers may require system access to modify or upload resources directly. Call it "real" access rights. To make it more interesting there may also be content editors who can edit pages. This often is done through a Content Management System (CMS). A CMS may allow fine-grained access, meaning an editor can only edit specific sections of a web site. Call that "virtual" access rights. Web site visitors do not require any such access: they just see whatever the web server allows them to see. If the web server can read something then it'll show them that something.
So in essence the Linux permissions are for system access, not for web site users. Makes sense, thanks!

However, in the case of a CMS, where, let's say an editor could update existing web pages on the server, does anything need to be done at the Linux permission level to accommodate this, or is this managed via CMS administration only?
 
Old 01-16-2013, 11:39 AM   #5
jpollard
Senior Member
 
Registered: Dec 2012
Location: Washington DC area
Distribution: Fedora, CentOS, Slackware
Posts: 4,654

Rep: Reputation: 1255Reputation: 1255Reputation: 1255Reputation: 1255Reputation: 1255Reputation: 1255Reputation: 1255Reputation: 1255Reputation: 1255
You need to look at the permissions from the view of the apache server... which is a standin for the "thousands of external users".

All such users connect to the apache server, therefore, their access is that of the apache server.

And that is how the permissions are interpreted.

Normally, the CMS also runs as apache... though it doesn't have to. These two "users" do need to share something - at a minimum, other. better is group. What this does is prevent the general users from exploiting a bug in apache to gain write access to the data.

In a RH/CentOS based system, the apache user cannot even access /tmp (wrong SELinux security label), so they really don't get much. Only directories read or write by the apache server can be accessed. With the CMS being in a different user, apache doesn't even need write access (only read.. and search for directories - and SELinux permissions). Thus general breakins fail at nearly everything useful.

Database updates are still a problem - passwords are usually embedded in things readable by apache, and that can cause issues. But the static pages would be protected.
 
Old 01-16-2013, 11:48 AM   #6
unSpawn
Moderator
 
Registered: May 2001
Posts: 29,332
Blog Entries: 55

Rep: Reputation: 3533Reputation: 3533Reputation: 3533Reputation: 3533Reputation: 3533Reputation: 3533Reputation: 3533Reputation: 3533Reputation: 3533Reputation: 3533Reputation: 3533
Quote:
Originally Posted by Habitual View Post
I did wonder what he talked about ;-p Thanks for finding it.


Quote:
Originally Posted by misterpiddles View Post
(..) in the case of a CMS, where, let's say an editor could update existing web pages on the server, does anything need to be done at the Linux permission level to accommodate this, or is this managed via CMS administration only?
Generally speaking a CMS runs on top of the web server so if any access rights need to be changed it'll be handled at CMS installation time. Another way could be to think of access rights in layers:
Code:
                       [visitor]    [editor]
                               \     /
                                \   /
==========================[application]===============
                                |  |
                                x  |
                           [web server]
==network level========================================
                                   |
                                   x
                        [web server user]
                                |
         [local user]           |
               |                |
[root]         |                |
  |            |                |
  v            v                v
==file system===========================================
 
Old 01-16-2013, 11:53 AM   #7
unSpawn
Moderator
 
Registered: May 2001
Posts: 29,332
Blog Entries: 55

Rep: Reputation: 3533Reputation: 3533Reputation: 3533Reputation: 3533Reputation: 3533Reputation: 3533Reputation: 3533Reputation: 3533Reputation: 3533Reputation: 3533Reputation: 3533
Quote:
Originally Posted by jpollard View Post
(..) Thus general breakins fail at nearly everything useful.
...from sending spam and uploading toolkits and exploits to ripping out complete loginwd:email databases to name just a few "minor" glitches ;-p
 
Old 01-16-2013, 12:02 PM   #8
misterpiddles
LQ Newbie
 
Registered: Nov 2012
Location: Boston-ish, MA, USA
Distribution: Debian
Posts: 17

Original Poster
Rep: Reputation: Disabled
Ok, thanks all very much for the useful replies.

I certainly understand it now more than before, though I suspect if I work with a CMS down the line on Apache, I'll have to come back here for reference.
 
Old 01-17-2013, 05:36 AM   #9
jpollard
Senior Member
 
Registered: Dec 2012
Location: Washington DC area
Distribution: Fedora, CentOS, Slackware
Posts: 4,654

Rep: Reputation: 1255Reputation: 1255Reputation: 1255Reputation: 1255Reputation: 1255Reputation: 1255Reputation: 1255Reputation: 1255Reputation: 1255
Quote:
Originally Posted by unSpawn View Post
...from sending spam and uploading toolkits and exploits to ripping out complete loginwd:email databases to name just a few "minor" glitches ;-p
uploading toolkits can only be written to places apache has write access to (could store it in memory... but then the apache process has to not close the CGI...) So if apache can't write... And unless login/passwd/email is stored in a database where the db password is available, it can't access the /etc/passwd file or mail directories either. Sending spam is a potential problem though.

And as much as I despise using passwords for database access, I would prefer a non apache service to use a domain socket to accept/reply to such queries where the queries can be filtered for validity (and that process not have read/write access to anything except the database, and use syslog to log activity).
 
Old 01-17-2013, 09:08 AM   #10
unSpawn
Moderator
 
Registered: May 2001
Posts: 29,332
Blog Entries: 55

Rep: Reputation: 3533Reputation: 3533Reputation: 3533Reputation: 3533Reputation: 3533Reputation: 3533Reputation: 3533Reputation: 3533Reputation: 3533Reputation: 3533Reputation: 3533
Quote:
Originally Posted by jpollard View Post
uploading toolkits can only be written to places apache has write access to (...)
What makes you think that isn't enough?


Quote:
Originally Posted by jpollard View Post
And unless login/passwd/email is stored in a database where the db password is available, it can't access the /etc/passwd file or mail directories either.
I was talking database contents there, not direct file system access.


Quote:
Originally Posted by jpollard View Post
Sending spam is a potential problem though.
That would be kind of an understatement ;-p
 
Old 01-17-2013, 10:13 AM   #11
jpollard
Senior Member
 
Registered: Dec 2012
Location: Washington DC area
Distribution: Fedora, CentOS, Slackware
Posts: 4,654

Rep: Reputation: 1255Reputation: 1255Reputation: 1255Reputation: 1255Reputation: 1255Reputation: 1255Reputation: 1255Reputation: 1255Reputation: 1255
SELinux blocks apache from writing to any file that isn't labeled for apache write - the type must be either httpd_user_content_rw_t or httpd_sys_rw_content_t. Without these labels apache is unable to write to a file or create files.

SELinux blocks apache from reading anything that isn't labeled httpd_user_content_t or httpd_sys_content_t (or the universal sharing label... which shouldn't be used).

All it really means is that if the MAC label doesn't allow access, then apache doesn't have access even if the DAC permissions allow it.

It compartmentalizes apache into a rather small jail. It can't even run CGI scripts that don't have the proper label (httpd_sys_script_exec_t).

Last edited by jpollard; 01-17-2013 at 10:15 AM.
 
Old 01-17-2013, 11:44 AM   #12
sneakyimp
Senior Member
 
Registered: Dec 2004
Posts: 1,003

Rep: Reputation: 67
In my experience (which is mostly with PHP), installations can vary a lot. When users access a website, they contact the machine on port 80 (or port 443 for HTTPS) where Apache (or some other web server) is listening and ask Apache for the files. Apache which has system access, runs on the server as some user. On Debian based linux distros, this user is typicall www-data. On Red Hat / CentOS based machines, this user is typically apache. HOWEVER, in some configurations often used in shared hosting, the user might be something else depending on the domain. I'm not sure which Apache module does it, but if I have a username sneakyimp that I use for system access to upload my files and administrate my account, the server may be configured such that all Apache actions for my account (which might include several domains) will run not as the master apache user but rather as sneakyimp. Personally, I find this unsettling because it means that the apache user, sneakyimp, owns all of the files in my webroot. If one file has a security flaw, the apache user (sneakyimp) might be able to easily read, write, and execute any files connected to my account, depending on the nature of the security flaw. I prefer to limit read and write access to apache only as much as is absolutely necessary.

For Apache to read any file directly, whether it be a html file, a jpeg, or a PHP script to execute, the apache user must have access to this file either as user, group, or "everyone". This is why you usually see files in a webroot having --r for the everyone part of the permissions. It doesn't have to be this way. You could assign the apache user as group owner for all these files and set the everyone bits to ---.

There are also other files that apache may gain access to by requesting a service. When MySQL or some other database is brought into the equation, Apache connects to the database server on some port (typically port 3306 for mysql servers) and then the mysql server (which typically runs as user mysql -- a "user" with system access) will read and write files that belong to it.

If you would like to find out in PHP the name of the apache user for your domain, try putting this script on your web server:
PHP Code:
<?php
passthru
("whoami");
?>

Last edited by sneakyimp; 01-17-2013 at 11:46 AM.
 
Old 01-17-2013, 12:05 PM   #13
unSpawn
Moderator
 
Registered: May 2001
Posts: 29,332
Blog Entries: 55

Rep: Reputation: 3533Reputation: 3533Reputation: 3533Reputation: 3533Reputation: 3533Reputation: 3533Reputation: 3533Reputation: 3533Reputation: 3533Reputation: 3533Reputation: 3533
Quote:
Originally Posted by jpollard View Post
(..) All it really means is that if the MAC label doesn't allow access, then apache doesn't have access even if the DAC permissions allow it. (..)
Thanks for explaining SELinux to me. I think though in your explanation you may have assumed the file wasn't written by the web server user?
 
Old 01-17-2013, 12:16 PM   #14
misterpiddles
LQ Newbie
 
Registered: Nov 2012
Location: Boston-ish, MA, USA
Distribution: Debian
Posts: 17

Original Poster
Rep: Reputation: Disabled
So looking at the httpd.conf file, the User and Group are being set to the same value as the owner and group for all the Linux files on the site. The value is the App Name, we'll call it "appuser".

A typical file's permission on the site looks like this:

-rwxr-xr-- 1 appuser appuser 1923 Oct 18 16:21 phpview.php

Given the Apache user and group are the same as the Linux user and group, should the files not have write permissions for either user or group for security purposes?

And if the answer is yes, that there should only be read authority, how would we copy files from a testing environment to the live site without getting permission errors?
 
Old 01-17-2013, 12:43 PM   #15
jpollard
Senior Member
 
Registered: Dec 2012
Location: Washington DC area
Distribution: Fedora, CentOS, Slackware
Posts: 4,654

Rep: Reputation: 1255Reputation: 1255Reputation: 1255Reputation: 1255Reputation: 1255Reputation: 1255Reputation: 1255Reputation: 1255Reputation: 1255
Quote:
Originally Posted by unSpawn View Post
Thanks for explaining SELinux to me. I think though in your explanation you may have assumed the file wasn't written by the web server user?
Which file? Apache is only allowed to access files and directories with the appropriate security labels. By default on RH/CentOS/Fedora, RH may not access any files outside /var/www/ (and read only there). And only has read/execute in /var/www/cgi-bin. For anything else, the admin has to enable it using SELinux boolean flags (to enable public web files in the UserDir specified).
 
  


Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off



Similar Threads
Thread Thread Starter Forum Replies Last Post
DISCUSSION: Quick and Dirty Guide to Linux File Permissions bulliver LinuxAnswers Discussion 32 12-19-2011 11:36 PM
DISCUSSION: NNP's Quick and Dirty Linux Kernel Compilation Guide NNP LinuxAnswers Discussion 0 03-09-2006 03:25 PM
Quick and dirty cryptography guide. Linux.tar.gz Linux - Security 4 03-25-2005 03:16 PM
quick and dirty guide on installing GRUB markus1982 Linux - Software 1 05-26-2003 12:56 PM
quick and dirty guide on installing grub markus1982 Linux - General 0 04-10-2003 04:56 AM


All times are GMT -5. The time now is 03:52 AM.

Main Menu
Advertisement
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration