savannah-hackers-public
[Top][All Lists]
Advanced

[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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]