setup for localhost web (PHP) development

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

setup for localhost web (PHP) development

Gour
Hello,

I'm interested what would be recommended way to configure my desktop
machine as localhost for web (PHP) development?

I've few entries like:

127.0.0.1 foo.local bar.local

in my /etc/hosts in order to be able to access development sites via
aliases, e.g. http://foo.local/

Moreover, I'd like to work on the sites under my regular user account
using my uid/gid and keep the development under VCS.

I admit I'm not overly familiar with Apache2 setup and certainly not on
Fedora (on Debian it is configured a bit different) to which I recently
migrated.

As a temporary workaround to make it somehow work I configured Apache to
run under my uid/gid, put my foo/bar sites under /var/www/html as
VirtualHosts, chown-ed them as uid/gid and chmod-ed to 775.

Finally, I symlinked them to ~/prj/www/{foo,bar}...

I have feeling it's pretty ugly setup, so I'm humbly looking for some
improvement tips how to configure Apache+PHP for working on several
web sites on localhost machine?


Sincerely,
Gour

--
Thus the wise living entity's pure consciousness becomes covered by
his eternal enemy in the form of lust, which is never satisfied and
which burns like fire.

_______________________________________________
users mailing list -- [hidden email]
To unsubscribe send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: setup for localhost web (PHP) development

Bryon Adams-2
On 12/5/2016 09:13, Gour wrote:

> Hello,
>
> I'm interested what would be recommended way to configure my desktop
> machine as localhost for web (PHP) development?
>
> I've few entries like:
>
> 127.0.0.1 foo.local bar.local
>
> in my /etc/hosts in order to be able to access development sites via
> aliases, e.g. http://foo.local/
>
> Moreover, I'd like to work on the sites under my regular user account
> using my uid/gid and keep the development under VCS.
>
> I admit I'm not overly familiar with Apache2 setup and certainly not on
> Fedora (on Debian it is configured a bit different) to which I recently
> migrated.
>
> As a temporary workaround to make it somehow work I configured Apache to
> run under my uid/gid, put my foo/bar sites under /var/www/html as
> VirtualHosts, chown-ed them as uid/gid and chmod-ed to 775.
>
> Finally, I symlinked them to ~/prj/www/{foo,bar}...
>
> I have feeling it's pretty ugly setup, so I'm humbly looking for some
> improvement tips how to configure Apache+PHP for working on several
> web sites on localhost machine?
>
>
> Sincerely,
> Gour
>

I think you went a bit out of your way by changing the Apache user, but
I believe Virtual Hosts are what you need. I had used them to make
personal web pages in home directories.
_______________________________________________
users mailing list -- [hidden email]
To unsubscribe send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: setup for localhost web (PHP) development

Tim-163
In reply to this post by Gour
Allegedly, on or about 05 December 2016, Gour sent:
> I'm interested what would be recommended way to configure my desktop
> machine as localhost for web (PHP) development?
>
> I've few entries like:
>
> 127.0.0.1 foo.local bar.local
>
> in my /etc/hosts in order to be able to access development sites via
> aliases, e.g. http://foo.local/

You may strike problems using .local as a domain name.  If you're just
doing it on the same machine, it'll probably be fine.  But if you have
other computers on that LAN, some of them *may* only use .local with the
type of IPs and name resolution methods intended for that domain
(bonjour, zeroconf, 169.254.0.0/16 IP range, non-standard DNS services,
non-standard DNS clients, and non-standard name querying ports, etc).

But your idea is on the right track (IP, domain name lists, in
your /etc/hosts files on all computers in the LAN), just avoid using
special reserved names, if they're not appropriate.

> Moreover, I'd like to work on the sites under my regular user account
> using my uid/gid and keep the development under VCS.

I do that all the time, but with flat HTML files.  As the super-user I
set up initial directory permissions for the web server directory root
that let me create files in there, as myself.  Then, I can make files
and directories inside it as my own user ID.

NB:  If you don't want to change /var/www/html to be owned by you, you
can create a sub-directory inside it that is, and work from inside
there.

When using applications to create your files, instead of hand-carving
HTML, you need to configure *those* applications to create files with
the right IDs.  It's that middle process (your PHP VCS) that you need to
adjust, not the web server.

On that note, it's not necessary that it creates files owned by you, it
could have its own IDs.  It is, however, very important not to have the
files owned by the user the webserver runs as.

> I admit I'm not overly familiar with Apache2 setup and certainly not on
> Fedora (on Debian it is configured a bit different) to which I recently
> migrated.
>
> As a temporary workaround to make it somehow work I configured Apache to
> run under my uid/gid, put my foo/bar sites under /var/www/html as
> VirtualHosts, chown-ed them as uid/gid and chmod-ed to 775.
>
> Finally, I symlinked them to ~/prj/www/{foo,bar}...

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.

example.html -rw----r--

rw- Owner readable and writable, for you to work with your files.
--- Group user permissions are generally ignored.
r-- Other user's readable permissions pertinent to Apache's access.

(Files can have execute bits set, and Apache treats them specially,
allowing it to parse the file and insert variables, follow instructions
in the HTML, etc.)

Directories are similar, with the exception that you also need to add
the executable bit to the other permissions.

example/ drwx---r-x

rwx Owner readable, writable, executable for *you* to work with your files.
--- Group user permissions are generally ignored.
r-x Other user's readable and directory-accessible permissions pertinent to Apache's access.

By and large, suitable permissions (as noted above) are usually created
by default, and won't need you to change them.

You do not want to create files owned by the apache user, nor change
Apache to run as the user that owns the files.  This, now, gives Apache
permission to write arbitrary files, which is bad security.  If you do
need to be able to use a webserver to create files, you don't want to
let Apache directly do that.  There's needs to be a handler, in between,
that does this securely.

While experimenting on an isolated LAN it's easy to think that this
doesn't really matter.  But you're learning a bad habit, and not
learning what needs to be done to do this properly in the real world.

SELinux, if you're using it, is another consideration.  Suitable
contexts need to be attributed to the directories and files for Apache
to be able to serve them.

Again, if you create the files in their usual locations, they usually
get given the correct SELinux attributes for this to work.  What can be
a stumbling block is making files somewhere else in the directory tree,
and moving them over.  The original attributes (which won't allow
serving), stay with the files.  Copying files works fine, because when
they get written to their new location, they get the appropriate (for
serving) attributes written to the copies.

And again, while it may seem easier to disable SELinux, it's an
important tool for safety of a system, and it's far better to learn how
to do security properly, than abandon it.  Especially when you're
playing with dynamically generated content that can be controlled by
outsiders through their webbrowser or malicious robots.

I wouldn't mess with the apache users (what it runs as), the normal way
it runs works fine.  If your server is public facing, or accessible by
untrustworthy devices on your LAN, having it run unusually will open
security issues.

--
[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.

Windows, it's enough to make a grown man cry!


_______________________________________________
users mailing list -- [hidden email]
To unsubscribe send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: setup for localhost web (PHP) development

Gour
On Tue, 06 Dec 2016 07:47:34 +1030
Tim <[hidden email]> wrote:

> You may strike problems using .local as a domain name.  If you're just
> doing it on the same machine, it'll probably be fine.  

My machine is not in the LAN, iow. single desktop machine, but this part
is anyway easily solvable by using some other aliases...

> I do that all the time, but with flat HTML files.  As the super-user I
> set up initial directory permissions for the web server directory root
> that let me create files in there, as myself.  Then, I can make files
> and directories inside it as my own user ID.

That works for me for flat HTML files - /var/www/html is owned by my
uid/gid, but have problems serving PHP files.

> When using applications to create your files, instead of hand-carving
> HTML, you need to configure *those* applications to create files with
> the right IDs.  It's that middle process (your PHP VCS) that you need
> to adjust, not the web server.

I see...

> On that note, it's not necessary that it creates files owned by you,
> it could have its own IDs.  

> It is, however, very important not to have the files owned by the user
> the webserver runs as.

OK. Now I've reverted web server to run as apache:apache, but have to
solve PHP-related problem...

> 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.

That was it...In the meantime I also discovered 'official' docs in
regard: https://learn.getgrav.org/basics/requirements

Now, everything is OK: :-)

> While experimenting on an isolated LAN it's easy to think that this
> doesn't really matter.  But you're learning a bad habit, and not
> learning what needs to be done to do this properly in the real world.

I agree.

> SELinux, if you're using it, is another consideration.  Suitable
> contexts need to be attributed to the directories and files for Apache
> to be able to serve them.

I did get some alerts and fixed them.

> And again, while it may seem easier to disable SELinux, it's an
> important tool for safety of a system, and it's far better to learn
> how to do security properly, than abandon it.  Especially when you're
> playing with dynamically generated content that can be controlled by
> outsiders through their webbrowser or malicious robots.

I also do not want to disable it.

> I wouldn't mess with the apache users (what it runs as), the normal
> way it runs works fine.  

It runs now as apache:apache and everything is good.

Thank you for assistance!


Sincerely,
Gour

--
As the ignorant perform their duties with attachment to results,
the learned may similarly act, but without attachment, for the
sake of leading people on the right path.

_______________________________________________
users mailing list -- [hidden email]
To unsubscribe send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: setup for localhost web (PHP) development

Bill Shirley
In reply to this post by Tim-163



On 12/5/2016 4:17 PM, Tim wrote:

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.

example.html -rw----r--

rw- Owner readable and writable, for you to work with your files.
--- Group user permissions are generally ignored.
r-- Other user's readable permissions pertinent to Apache's access.

(Files can have execute bits set, and Apache treats them specially,
allowing it to parse the file and insert variables, follow instructions
in the HTML, etc.)

Directories are similar, with the exception that you also need to add
the executable bit to the other permissions.

example/ drwx---r-x

rwx Owner readable, writable, executable for *you* to work with your files.
--- Group user permissions are generally ignored.
r-x Other user's readable and directory-accessible permissions pertinent to Apache's access.

This is insecure.  If I have a local account I can copy all your code.  Or lookup your database
id and password.
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.

Bill


_______________________________________________
users mailing list -- [hidden email]
To unsubscribe send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: setup for localhost web (PHP) development

Tim-163
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 -- [hidden email]
To unsubscribe send an email to [hidden email]