Tim:
>> Generally speaking, files to be served from /var/www/html are served as
>> files owned by the author, with world-readable permissions (Apache reads
>> files as "other" users.
Bill Shirley:
> This is insecure. If I have a local account I can copy all your code.
> Or lookup your database id and password.
Only if you stupidly put such data within the doc root directories.
The permissions I mention are the normal way that Apache works. Of
course, you only put files inside the directory root that are meant to
be world readable (web pages, images). Scripting used for dynamic pages
(CGI, etc.), goes into scripting directories, that are outside of the
document root, and have to be parsed to be served. They have their own
set of rules about how they're handled. And if you have data that will
be parsed by some handler to be served, that data is stored outside of
those directories, and only accessible through the handler.
e.g. /var/www/html (flat pages, images, etc.)
/var/www/cgi (scripting)
/var/www/data (data used by your scripts)
/var/www/html is mapped into http://www.example.com/
/var/www/cgi is mapped into http://www.example.com/cgi
/var/www/data is not mapped into it, at all
Although cgi is mapped into a URI that appears to be within the root (to
the outside world), the actual files are outside of the directory root,
and cannot be directly accessed (you can't see the files, nor the
content, you can only see their output processed by their handler).
Likewise, data is outside of the directory root, cannot be directly
accessed, can only be accessed by your scripts (which must be written
securely, in themselves).
The problem with giving Apache any kind of ownership to files that it
can serve, is that you nearly always end up giving it permission to
write to those files, too (directly, or indirectly). Since Apache is
operated from the outside world (browsing), that's a security/stability
problem. Hence why you only allow it read-access to the "other" users.
It has always been best practice to never give any kind of ownership to
files that have the same ID as the server itself.
Another one of the big security blunders that lots of people make is
putting everything that will go through the server inside
of /var/www/html. When you only have data that's okay for the world to
read inside there (your webpages, that they're going to read, anyway),
there's no problem with that data being world-readable. It's meant to
be, anyway.
There's a great deal of logic in data that's meant to be world readable
having world readable permissions, separate from owner's permissions.
You have read and write permissions for you files as you ought to have,
and world permissions are set for public files as they ought to be.
> A better solution is (assuming your id=gour):
> find /var/www/html -type d -exec chmod 2750 {} \;
> find /var/www/html -type f -exec chmod 640 {} \;
> chown -R gour:apache /var/www/htm/*
>
> Now you can edit, apache can read-only, and the world gets nothing.
> All new files/folders get apache as the group id since you're using
> the group sticky bit. Create new folders with permissions 2750; new
> files with 640.
Once you give file ownership to Apache, you have to be damn sure that
every file, and every directory (including parents), do not have write
access to them. A problem with that is often that default permissions
for files and directories include group write permission. So you have
to change that, and keep an eye on every file you create. People create
files and copy or move them to the doc root, they use applications that
generate them, etc. All of that has to be checked.
--
[tim@localhost ~]$ uname -rsvp
Linux 3.9.10-100.fc17.x86_64 #1 SMP Sun Jul 14 01:31:27 UTC 2013 x86_64
Boilerplate: All mail to my mailbox is automatically deleted, there is
no point trying to privately email me, I only get to see the messages
posted to the mailing list.
_______________________________________________
users mailing list -- users@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to users-leave@xxxxxxxxxxxxxxxxxxxxxxx
