Hi folks,

Yet again linux permissions confuse me. Can someone offer any insight
please.

I have written a CGI app that takes allows users to upload image files
from their browser to a web server. I wanted to have the directory
that the uploaded files loads to in /home/dave/UploadedPhotos so that
it would be outside the standard web structure.

I set permissions on the upload directory to 777 but no matter what I
tried, it wouldn't work.

Eventually I put UploadedPhotos into /var/www/html and gave it 777
permissions, and this worked.

I have two (related) questions. Why do I get a permissions failure
when trying to write to a directory in /home/dave yet the same
permissions work for a directory in /var/www/html?

And why do I need execute permissions on the directory?

In principle I aught to be able to use 602, as I never want to execute
anything in that directory, [...

the Perl CGI script will only ever write to that directory, and
reading will be done manually by the service owner.

The Group and Owner of 'UploadedPhotos' (and in fact the 'html'
directory within /var/www) are set to 'dave'.

I have written a CGI app that takes allows users to upload image files
from their browser to a web server. I wanted to have the directory
that the uploaded files loads to in /home/dave/UploadedPhotos so that
it would be outside the standard web structure.

On Monday 19 October 2009 12:34 in comp.os.linux.setup, somebody

identifying as Dave wrote...
Hi folks,

Yet again linux permissions confuse me. Can someone offer any insight
please.

I have written a CGI app that takes allows users to upload image files
from their browser to a web server. I wanted to have the directory
that the uploaded files loads to in /home/dave/UploadedPhotos so that
it would be outside the standard web structure.

That's not the right place to do it either way.  Home directories are
not intended for public use.  Anything pertaining to the data of a
webserver should go under */var/www* or possibly under */srv* - the
latter is usually not implemented on GNU/Linux, but it's part of the
FHS 2.3.

I set permissions on the upload directory to 777 but no matter what I
tried, it wouldn't work.

Eventually I put UploadedPhotos into /var/www/html and gave it 777
permissions, and this worked.

I have two (related) questions. Why do I get a permissions failure
when trying to write to a directory in /home/dave yet the same
permissions work for a directory in /var/www/html?

Because the permissions on a directory also depend on those of the
parent directory.  If nobody else but you and the users in your primary
group have access to */home/dave* then they won't be able to write to
any subdirectory thereof, no matter what the permissions on that
subdirectory are.

Or to give you an example...  Suppose you have your home directory
*/home/dave* set up with "drwxr-x---" or "drwx------" permissions.  If
under those circumstances you were to create a subdirectory to that
with the absolute path */home/dave/UploadedPhotos* and "drwxrwxrwx"
permissions, then the permissions on your actual home directory would
prevent anyone from accessing that subdirectory, since they'd need to
traverse your home directory, which requires that they have "r" and "x"
access on your home directory.

Besides, you really wouldn't want your home directory to be
world-writeable anyway.

And why do I need execute permissions on the directory?

Execute permission on a directory gives a user the permission to
traverse the directory - it has nothing to do with the right to execute
anything in that directory, because that's a permission on the actual
file itself, not on the directory.

You should think of a directory as a special kind of file - and in
reality, that's sort of what it is - which contains the names of other
files and other directories.  Read and write permissions on a directory
pertain to the reading of the list of files and subdirectories in that
directory, or the modifying of the directory list.  So for instance,
deleting a file is a write operation on the directory containing the
file, not on the file itself - if the file is hardlinked, you wouldn't
even be removing the file anyway, because in UNIX a filename is only an
entry in a directory with a pointer to the inode of the file.

And so, if a directory contains a subdirectory, then what this in
reality means is that the list of entries in the directory contains a
name and a pointer to an inode for another directory.  In order to
access that other directory and its contents, you need both read and
execute permission set on the parent.  With read permission only on the
parent, you would only get to see the subdirectory's name, but not
access it.

In principle I aught to be able to use 602, as I never want to execute
anything in that directory, [...

See above.

the Perl CGI script will only ever write to that directory, and
reading will be done manually by the service owner.

The Group and Owner of 'UploadedPhotos' (and in fact the 'html'
directory within /var/www) are set to 'dave'.

Yes, but */var/www* itself would normally be owned by root:root and set
up as world-readable and world-traversable.  You need both of those
permissions on the parent (and its parent, and its parent, and so on)
in order to read from, write to or traverse a subdirectory thereof.

On Oct 19, 12:14=A0pm, Aragorn <arag... at (no spam) chatfactory.invalid> wrote:
On Monday 19 October 2009 12:34 in comp.os.linux.setup, somebody

identifying as Dave wrote...
Hi folks,

Yet again linux permissions confuse me. Can someone offer any insight
please.

I have written a CGI app that takes allows users to upload image files
from their browser to a web server. I wanted to have the directory
that the uploaded files loads to in /home/dave/UploadedPhotos so that
it would be outside the standard web structure.

That's not the right place to do it either way. =A0Home directories are
not intended for public use. =A0Anything pertaining to the data of a
webserver should go under */var/www* or possibly under */srv* - the
latter is usually not implemented on GNU/Linux, but it's part of the
FHS 2.3.

Hi, thanks very much for responding.

What I'm after is a directory ideally outside of the web structure, as
under normal circumstances the only thing accessing it would be the
CGI Perl script writing the file, and I don't want anyone to be able
to read it from the web.

I set permissions on the upload directory to 777 but no matter what I
tried, it wouldn't work.

Eventually I put UploadedPhotos into /var/www/html and gave it 777
permissions, and this worked.

I have two (related) questions. Why do I get a permissions failure
when trying to write to a directory in /home/dave yet the same
permissions work for a directory in /var/www/html?

Because the permissions on a directory also depend on those of the
parent directory. =A0If nobody else but you and the users in your primary
group have access to */home/dave* then they won't be able to write to
any subdirectory thereof, no matter what the permissions on that
subdirectory are.

Okay, I think I understand that.

Or to give you an example... =A0Suppose you have your home directory
*/home/dave* set up with "drwxr-x---" or "drwx------" permissions. =A0If
under those circumstances you were to create a subdirectory to that
with the absolute path */home/dave/UploadedPhotos* and "drwxrwxrwx"
permissions, then the permissions on your actual home directory would
prevent anyone from accessing that subdirectory, since they'd need to
traverse your home directory, which requires that they have "r" and "x"
access on your home directory.

Doesn't that just duplicate the efforts of each other i.e needing both
r & x?

Besides, you really wouldn't want your home directory to be
world-writeable anyway. ;-)

Indeed.

And why do I need execute permissions on the directory?

Execute permission on a directory gives a user the permission to
traverse the directory - it has nothing to do with the right to execute
anything in that directory, because that's a permission on the actual
file itself, not on the directory.

You should think of a directory as a special kind of file - and in
reality, that's sort of what it is - which contains the names of other
files and other directories. =A0Read and write permissions on a directory
pertain to the reading of the list of files and subdirectories in that
directory, or the modifying of the directory list. =A0So for instance,
deleting a file is a write operation on the directory containing the
file, not on the file itself - if the file is hardlinked, you wouldn't
even be removing the file anyway, because in UNIX a filename is only an
entry in a directory with a pointer to the inode of the file.

I think I'm still struggling over the difference between r & x on a
directory. Have I got this right:
r permissions allow the reading of the directory list,
x permissions allow me to read the directory list of a sub directory,
if that directory has r permissions?

And so, if a directory contains a subdirectory, then what this in
reality means is that the list of entries in the directory contains a
name and a pointer to an inode for another directory. =A0In order to
access that other directory and its contents, you need both read and
execute permission set on the parent. =A0With read permission only on the
parent, you would only get to see the subdirectory's name, but not
access it.

In principle I aught to be able to use 602, as I never want to execute
anything in that directory, [...

See above. ;-)

I've put permissions of 703, and that seems to now be allowing
everything I want to allow.

the Perl CGI script will only ever write to that directory, and
reading will be done manually by the service owner.

The Group and Owner of 'UploadedPhotos' (and in fact the 'html'
directory within /var/www) are set to 'dave'.

Yes, but */var/www* itself would normally be owned by root:root and set
up as world-readable and world-traversable. =A0You need both of those
permissions on the parent (and its parent, and its parent, and so on)
in order to read from, write to or traverse a subdirectory thereof.

So a parent directory only needs r (and x) permissions, yet will still
allow a write into a sub directory?

Many thanks,

Dave

The subdirectory has nothing to do with the directory, except for access.
If you have r permisison but not x, you can do
ls dirname
and see the names in the directory. You cannot however access any of those files
or subdirectories.
x does not allow reading
ls dirname
will show nothing.
But if you know that there is a subdirectory called subdir, then you can do
cd dirname/subdir
and get there, or ls dirname/subdir and list the subdirectory (assuming it has r
permission)

I think I'm still struggling over the difference between r & x on a
directory. Have I got this right:
r permissions allow the reading of the directory list,
x permissions allow me to read the directory list of a sub directory,
if that directory has r permissions?

Hi folks,

Yet again linux permissions confuse me. Can someone offer any insight
please.

I have written a CGI app that takes allows users to upload image files
from their browser to a web server. I wanted to have the directory
that the uploaded files loads to in /home/dave/UploadedPhotos so that
it would be outside the standard web structure. I set permissions on
the upload directory to 777 but no matter what I tried, it wouldn't
work.

Eventually I put UploadedPhotos into /var/www/html and gave it 777
permissions, and this worked.

I have two (related) questions. Why do I get a permissions failure
when trying to write to a directory in /home/dave yet the same
permissions work for a directory in /var/www/html?

And why do I need execute permissions on the directory? In principle I
aught to be able to use 602, as I never want to execute anything in
that directory, the Perl CGI script will only ever write to that
directory, and reading will be done manually by the service owner.

The Group and Owner of 'UploadedPhotos' (and in fact the 'html'
directory within /var/www) are set to 'dave'.

Any pointers gratefully received.

Many thanks,

Dave