Re: [Savannah-hackers-public] SubversionException: 13 - Can't open file '/srv/svn/gnueval/db/fs-type': Permission denied

[Ineiev]

On Sun, Feb 25, 2024 at 12:23:54AM -0700, Bob Proulx 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.

Private groups with CVS repositories have been existing since 2001.
I don't think the layout of CVS repositories had any changes
in the last two decades. in 2006 (when Savane Git history starts),
Cvs.pm already sets the permissions of new repositories according to
the is_public field.

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

/ is world-readable, isn't it? and typical $HOME as well.

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

Still blocking access to that file does mitigate those attacks. 
(Moving it out of public directory sometimes doesn't e.g. when users
are allowed to create symbolic links.)

> It used to be that people wrote firewall scripts allowing everything
> but blocking what they wanted to block.
> 
>     ACCEPT ALL
>     DROP 1433
>     DROP 1434
...
> 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.

I'm not sure the analogy applies very well. we have very few private
groups, their number isn't likely to grow considerably, and it's
clear if the given repository should be public or not.

Then, we do use file permissions (complicated with ACLs) to limit
the write access; why can't we use them to limit the read access?

signature.asc
Description: PGP signature