[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Savannah-hackers-public] SubversionException: 13 - Can't open file
From: |
Bob Proulx |
Subject: |
Re: [Savannah-hackers-public] SubversionException: 13 - Can't open file '/srv/svn/gnueval/db/fs-type': Permission denied |
Date: |
Sun, 25 Feb 2024 00:23:54 -0700 |
Ineiev wrote:
> I'm not sure why. the permissions will prevent anonymous access.
> that's what Savannah has always done with CVS directories of private
> groups.
This is in a PUBLIC DIRECTORY. Everything has always assumed that all
of those files are publically accessible files. Trying to block a
list of private files from the default access of private files goes
against almost all security practices. Private files should be
located in a private directory to avoid the possibility entirely.
Here are some examples.
At one time people used to write PHP projects such that all of the
files were in a root directory. But usually one of those files must
contain the database access credentials. Call that config.php for
discussion since that was usually the name of it.
phpproject/index.php
phpproject/admin/config.php
phpproject/admin/index.php
Malicious agents found that often, very often, web sites were not
configured to block access to that file. It was often possible to
gain access to that private file because it was located in a public
directory. Due to that universially PHP projects never put the config
file in the public directory and now relocate that to a directory
outside of the public area. It avoids any possibility of malicious
access to it. Now the root is public and served but the include
directory is not made public avoiding those types of accidents.
phpproject/root/index.php
phpproject/root/admin/index.php
phpproject/include/config.php
It used to be that people wrote firewall scripts allowing everything
but blocking what they wanted to block.
ACCEPT ALL
DROP 1433
DROP 1434
DROP 1026
DROP 1026
DROP 1027
DROP 1027
DROP 1028
DROP 1028
DROP 6129
DROP 17300
...
But the problem is that there are an increasing number of malicious
attacks and this strategy was not sustainable. Everyone has
universially moved to the opposite strategy of blocking everything by
default and then only allowing the things they want to allow.
DROP ALL
ACCEPT 22
ACCEPT 80
ACCEPT 443
That's a much better way to manage the risk.
Bob