12 Mar
2013
12 Mar
'13
1:29 p.m.
Dear All
I installed nginx and configured it to use /var/www/default-page as its
root folder for static web pages. ls -l /var/www returns
drwxrw----. 2 nginx nginx 4096 Mar 9 11:00 default-page
I do connect to the HOST where nginx is installed using ssh with
public key encryption: ssh my_user@HOST
my_user is just a plain vanilla user. I added my_user to group
nginx. I used my_user to create web content such as a index.html file.
ls -l /var/www/default-page returns
-rw-r--r--. my_user my_user 827 Mar 5 21:30 index.html
Does anyone see any security problems with this setup?
When I remove execute permission for nginx of default-page (drwxrw----
-> drw-rw----) I get an error message (403 Forbidden) when I want to
see index.html using a browser. I do not understand what nginx has to
execute in default-page folder. Can anyone explain why nginx uses this
execute permission?
Regards
Sam
--
Samuel Bächler
Obere Bläsistrasse 1
8049 Zürich
Web: boeser.ch
Tel: +41(0)43 817 46 28
Mob: +41(0)79 478 49 42
3:21 p.m.
On Tue, Mar 12, 2013 at 01:34:57PM +0000, Roger Light wrote:
On Tue, Mar 12, 2013 at 1:29 PM, Samuel Bächler
<baechler(a)boeser.ch> wrote:
No, it doesn't. "x" means "enter" - ie, you can't enter the
directory
if you don't have execute permission. You can "search"/"read" it,
but
only if you have read permission, and you can put files in there if
you have write permission.
The permissions you *actually* want for a web root are:
drwxr-xr-x root root
This is because the owner is allowed to change the permissions, so you
don't want your webserver to be able to write to its own serving
directory, and you need it to be able to search and actually chdir() into
that directory.
Cheers
MBM
(drwxrw----> -> drw-rw----)
"x" means "search" in the context of directories, not execute. 
5 p.m.
On 12 March 2013 15:21, Matthew Byng-Maddick <mbm(a)colondot.net> wrote:
The permissions you *actually* want for a web root are:
drwxr-xr-x root root
This is because the owner is allowed to change the permissions, so you
don't want your webserver to be able to write to its own serving
directory, and you need it to be able to search and actually chdir() into
that directory.
I'm glad someone else noticed that - it's a REALLY bad idea to have
anything inside the docroot writeable by the webserver, it makes it much
easier for you to cause Andy to send another security incident to the list.
Use Matthew's suggestion above, I've occasionally gone a step further and
use rwxr-x--- root:webserver.
--
Robert Gauld
http://www.robertgauld.co.uk
5:18 p.m.
On Tue, Mar 12, 2013 at 3:21 PM, Matthew Byng-Maddick <mbm(a)colondot.net> wrote:
On Tue, Mar 12, 2013 at 01:34:57PM +0000, Roger Light
wrote:
POSIX calls it search:
http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap04.html#tag…
who am I to argue? :) Regardless of the name, the important point is
that it is nothing to do with executing anything.
Samuel, it's worth spending some time figuring this all out for
yourself because it's not always obvious on first glance what the
behaviour will be. If you have a directory that you don't have write
permission for, you won't be able to create new files (or rename, or
delete), but you can modify files that already exist if you have the
appropriate file permissions, for example.
Matt - small world, we've met through juggling before.
Cheers,
Roger
On Tue, Mar 12, 2013 at 1:29 PM, Samuel Bächler
<baechler(a)boeser.ch> wrote:
No, it doesn't. "x" means "enter" - ie, you can't enter the
directory
if you don't have execute permission. You can "search"/"read" it,
but
only if you have read permission, and you can put files in there if
you have write permission. (drwxrw----> -> drw-rw----)
"x" means "search" in the context of directories, not execute.
5:40 p.m.
On Tue, Mar 12, 2013 at 05:18:28PM +0000, Roger Light wrote:
On Tue, Mar 12, 2013 at 3:21 PM, MBM wrote:
Yeah - fair point, in which case POSIX/SUS3 is using misleading terminology,
which'll make newbies get it wrong! :-( Search, to me, implies what the
directory read permission is for (ie. what're the contents of the directory)
On Tue, Mar 12, 2013 at 01:34:57PM +0000, Roger
Light wrote:
POSIX calls it search:
http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap04.html#tag…
who am I to argue? :) Regardless of the name, the important point is
that it is nothing to do with executing anything. On Tue, Mar 12, 2013 at 1:29 PM, Samuel Bächler
<baechler(a)boeser.ch> wrote:
No, it doesn't. "x" means "enter" - ie, you can't enter the
directory
if you don't have execute permission. You can "search"/"read" it,
but
only if you have read permission, and you can put files in there if
you have write permission. (drwxrw----> -> drw-rw----)
"x" means "search" in the context of directories, not execute. Samuel, it's worth spending some time figuring
this all out for
yourself because it's not always obvious on first glance what the
behaviour will be. If you have a directory that you don't have write
permission for, you won't be able to create new files (or rename, or
delete), but you can modify files that already exist if you have the
appropriate file permissions, for example.
Yes, very much so.
Matt - small world, we've met through juggling
before.
*blink* OK! Which Roger are you? I can't put a face to a name - what props?
:-)
Cheers
MBM
5:48 p.m.
On Tue, Mar 12, 2013 at 10:40:12AM -0700, Matthew Byng-Maddick wrote:
Yeah - fair point, in which case POSIX/SUS3 is using
misleading terminology,
which'll make newbies get it wrong! :-( Search, to me, implies what the
directory read permission is for (ie. what're the contents of the directory)
Search is a different permission from read. Search allows you to test
for the existence of a file within that directory; read allows you to
retrieve the full list. Running stat() on /foo/bar requires search
permission on /foo, but not read permission. The terminology is only
misleading if you don't appreciate that distinction.
13 Mar
13 Mar
12:28 a.m.
On Tue, Mar 12, 2013 at 05:48:08PM +0000, Stephen Bennett wrote:
On Tue, Mar 12, 2013 at 10:40:12AM -0700, Matthew
Byng-Maddick wrote:
What!?
What system do you use where the contents of the directory inode, when
read(2) is called, do not equal its actual contents. The whole point is
that you need the execute to enter, search or explore the directory.
stat(2) in the case you describe is an operation on the file inode, and
so just being able to tell that the inode is in the directory is not
enough, because you can't enter the directory to operate on that inode.
What you're seeing is that namei() (or whatever it's called in modern
linux, the function that resolves inode numbers from paths) cannot enter
that directory as that user because there is no execute permission. That
means that you get EACCES back, and so that's what you get back from stat().
It's specious to talk about the "existence of a file" - because you can
see whether the file exists by looking at the contents of the directory,
which you can see. You just can't see anything (metadata or data) about
that file, because you can't enter the directory to go and look,
WHATEVER the permissions on the file happen to be.
Cheers
MBM
Yeah - fair point, in which case POSIX/SUS3 is
using misleading terminology,
which'll make newbies get it wrong! :-( Search, to me, implies what the
directory read permission is for (ie. what're the contents of the directory)
Search is a different permission from read. Search allows you to test
for the existence of a file within that directory; read allows you to
retrieve the full list. Running stat() on /foo/bar requires search
permission on /foo, but not read permission. The terminology is only
misleading if you don't appreciate that distinction. 
10:54 a.m.
On Tue, Mar 12, 2013 at 05:28:47PM -0700, Matthew Byng-Maddick wrote:
It's specious to talk about the "existence of
a file" - because you can
see whether the file exists by looking at the contents of the directory,
which you can see.
Not if you don't have read permission to the directory, which was the
entire point. --x is sufficient privilege on a directory to stat one of
its children; r is not required.
12 Mar
12 Mar
9 p.m.
Thank you for the answers.
2013/3/12 Samuel Bächler <baechler(a)boeser.ch>
Dear All
I installed nginx and configured it to use /var/www/default-page as its
root folder for static web pages. ls -l /var/www returns
drwxrw----. 2 nginx nginx 4096 Mar 9 11:00 default-page
I do connect to the HOST where nginx is installed using ssh with
public key encryption: ssh my_user@HOST
my_user is just a plain vanilla user. I added my_user to group
nginx. I used my_user to create web content such as a index.html file.
ls -l /var/www/default-page returns
-rw-r--r--. my_user my_user 827 Mar 5 21:30 index.html
Does anyone see any security problems with this setup?
So, drwxr-xr-x my_user my_user will suit my needs best.
Regards
Sam
13 Mar
13 Mar
8:40 a.m.
On 12 March 2013 21:00, Samuel Bächler <baechler(a)boeser.ch> wrote:
Thank you for the answers.
2013/3/12 Samuel Bächler <baechler(a)boeser.ch>
Looks good to me.
--
Robert Gauld
http://www.robertgauld.co.uk
Dear All
I installed nginx and configured it to use /var/www/default-page as its
root folder for static web pages. ls -l /var/www returns
drwxrw----. 2 nginx nginx 4096 Mar 9 11:00 default-page
I do connect to the HOST where nginx is installed using ssh with
public key encryption: ssh my_user@HOST
my_user is just a plain vanilla user. I added my_user to group
nginx. I used my_user to create web content such as a index.html file.
ls -l /var/www/default-page returns
-rw-r--r--. my_user my_user 827 Mar 5 21:30 index.html
Does anyone see any security problems with this setup?
So, drwxr-xr-x my_user my_user will suit my needs best.
Regards
Sam
4068
days inactive
4069
days old
10 comments
6 participants
participants (6)
-
Matthew Byng-Maddick -
Robert Gauld -
Roger Light -
Samuel Bächler -
Stephen Bennett -
Stephen Bennett