Roger Binns | 6 Mar 2010 00:52

Re: cannot access the sqlite db


Greg Milby wrote:
> i think i have won... i made a symlink to a chmod'd777 db, 

That is a spectacularly bad thing to do.  You should *never* use symlinks
with SQLite databases.

The reason is that SQLite depends on putting the journal file in the same
directory as the database.  The journal is what ensures the database does
not become corrupt.  Other processes using SQLite will look for the journal
and do the right thing if it exists.  If you use a symlink then your
database will be in one directory and the journal in another - recipe for
disaster.

Note that it is ok for the path to include a symlink directory as the
journal and database will both end up in the same place.

Roger
Greg Milby | 6 Mar 2010 00:55
Picon

Re: cannot access the sqlite db

Thanks for the advice.  i'm just trying to learn more about sqlite/webpy - so nothing is riding on it at the moment. 

maybe i should just put the code AND db below webroot and map to it. have it execute and display in the web server root so there is no risk.
what do you think about that? does that sound viable?  this is my first sqlite experience - so all of the advice is appreciated.
-----------------------
Visit My Sites!
http://1-4-u.info | Don't send insanely long links!
www.syrbot.com | My Site
www.syrbotwebdesign.com | My Site New Design (Under Construction)
www.attackr.com | Latest Blog Posts
www.superantispyware.com/superantispyware.html?rid=3971 Remove All The Spyware - Not Just The Easy Ones!



On Fri, Mar 5, 2010 at 6:52 PM, Roger Binns <rogerb <at> rogerbinns.com> wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Greg Milby wrote:
> i think i have won... i made a symlink to a chmod'd777 db,

That is a spectacularly bad thing to do.  You should *never* use symlinks
with SQLite databases.

The reason is that SQLite depends on putting the journal file in the same
directory as the database.  The journal is what ensures the database does
not become corrupt.  Other processes using SQLite will look for the journal
and do the right thing if it exists.  If you use a symlink then your
database will be in one directory and the journal in another - recipe for
disaster.

Note that it is ok for the path to include a symlink directory as the
journal and database will both end up in the same place.

Roger
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkuRmTcACgkQmOOfHg372QT8YwCg25mu5Y90XJSh+KRIjOafHato
2j8AnRx0gDJpm4100LBbMohAo2j0JGhJ
=+yU2
-----END PGP SIGNATURE-----

Roger Binns | 6 Mar 2010 02:11

Re: cannot access the sqlite db


Greg Milby wrote:
> maybe i should just put the code AND db below webroot and map to it.

In general the only content you should have below the webroot is static
files with everything marked as read-only.

Scripts and similar are most convenient below the webroot but you need to be
very careful to ensure there is no private information in them.  For example
it is common with php to have the configuration info in a php file (eg
database server, username and password).  If the web server is misconfigured
in any way then it can end up displaying the contents of the file rather
than executing it.

Having the database below the webroot has the same problem.  It is even more
likely that it can be served up as is, which could be a very bad thing
depending on the contents.  It also requires that the web user be able to
write below the webroot, which means that a successful attacker will have
full control over what the web server sends out.

It is most convenient to have everything below the webroot since it will
make setting permissions easiest, but this is by far the easiest for hackers
to break, and gives them the best results for damage inflicted.

I'd suggest you do a search for all the web based attacks over the last 10
years to see what kind of attack vectors are used, various solutions, best
practises etc so you'll have an understanding of what the battlefield looks
like.

Remember that anyone can design and implement something they cannot break
themselves.  Many think that is sufficient.  I would however recommend
getting an external party to provide a security review.

Roger
Greg Milby | 6 Mar 2010 02:45
Picon

Re: cannot access the sqlite db

thanks for the objective view point.


-----------------------
Visit My Sites!
http://1-4-u.info | Don't send insanely long links!
www.syrbot.com | My Site
www.syrbotwebdesign.com | My Site New Design (Under Construction)
www.attackr.com | Latest Blog Posts
www.superantispyware.com/superantispyware.html?rid=3971 Remove All The Spyware - Not Just The Easy Ones!



On Fri, Mar 5, 2010 at 8:11 PM, Roger Binns <rogerb <at> rogerbinns.com> wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Greg Milby wrote:
> maybe i should just put the code AND db below webroot and map to it.

In general the only content you should have below the webroot is static
files with everything marked as read-only.

Scripts and similar are most convenient below the webroot but you need to be
very careful to ensure there is no private information in them.  For example
it is common with php to have the configuration info in a php file (eg
database server, username and password).  If the web server is misconfigured
in any way then it can end up displaying the contents of the file rather
than executing it.

Having the database below the webroot has the same problem.  It is even more
likely that it can be served up as is, which could be a very bad thing
depending on the contents.  It also requires that the web user be able to
write below the webroot, which means that a successful attacker will have
full control over what the web server sends out.

It is most convenient to have everything below the webroot since it will
make setting permissions easiest, but this is by far the easiest for hackers
to break, and gives them the best results for damage inflicted.

I'd suggest you do a search for all the web based attacks over the last 10
years to see what kind of attack vectors are used, various solutions, best
practises etc so you'll have an understanding of what the battlefield looks
like.

Remember that anyone can design and implement something they cannot break
themselves.  Many think that is sufficient.  I would however recommend
getting an external party to provide a security review.

Roger
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkuRq7MACgkQmOOfHg372QQcTgCgprtfjNfCpuH/6YuR386LCFwP
Q0AAoLssiTnzQ8eILc+ijn6bZpBJGie7
=Eec7
-----END PGP SIGNATURE-----


Gmane