Re: State of Perl-based database setup utilities for LedgerSMB 1.3

[Erik Huelsmann <..hidden..>]

On Sat, May 28, 2011 at 7:07 PM, Chris Travers <..hidden..> wrote:
> On Sat, May 28, 2011 at 9:08 AM, Adam Thompson <..hidden..> wrote:
>>> Where would the data be stored?  Do we require write permissions to
>>> the ledgersmb directory?
>>
>> Um, in the case I was describing, yes, I think so.  In the examples I've
>> seen, the administrator has the choice of either configuring their
>> webserver & system to allow the PHP script to write to the config file,
>> *or* updating the config file manually.  Which is what LSMB requires,
>> currently.
>>
>
> I think it's a lot safer not to trust the application with these
> things.

There you have my complete support. I'm running the OTRS ticket
tracking tool and it wanted me to open up write access to parts of its
directory structure in /usr. I *hate* it when tools require that:
libraries and servers which need write access should do that in the
/var hierarchy.

OTRS is a great example of a tool that comes with a great installation
script in Debian: you run the command 'apt-get install otrs2' and the
database, cron jobs and webserver all are configured when it
succesfully completes. That's what I envision for lsmb too, for its
first company database - created by packagers for specific
distributions.

>  If we were to go about that, I would suggest an addon, turned
> off by default, that would change permissions appropriately and
> provide an interface for making the changes.  But more to the point,
> that doesn't set up a database for accounting data.  I don't see an
> easy way to detect that prior to login since we have no access to the
> database server absent credentials supplied by the user.
>
> Now, this doesn't preclude a package manager from creating a database
> as part of the package installation process using the tools we
> provide.
>
> It's worth considering for a moment how little trust the application
> actually receives from a security perspective.  Unlike most open
> source applications, we made the decision to make application users
> into database roles.  One advantage here is that the application has
> no more access to data than the user who is currently logged in.  This
> reduces our security exposure a great deal by re-using a well-tested,
> mature authentication system in the background.  It also means that
> long-term a user could be granted the ability to connect to the same
> database using other tools and have the same rights applied across the
> board.

This is one of the great advantages why we choose specifically LSMB
1.3. With its model of coding as much as possible into the DB, it
shows that the authors know their limitations and acknowledge that
other programs (presumably lacking the checks and balances from LSMB)
may have a need to access the database read from or write to it. For
example external asset management tools or invoicing solutions.

> In other words, LedgerSMB doesn't authenticate users in 1.3, nor is it
> the final check against exceeding permissions.  These are both handled
> by PostgreSQL.
>
> So to create a database we have to obtain user permissions sufficient
> to create the database.

The other scenario would be to run LSMB with access to a user which
has enough permissions to do that when LSMB decides it's required to
do so. I'm not trusting LSMB enough to depend on that - after all, if
there turns out to be a security leak, anybody can start to create or
drop tables from my accounting system.


Bye,


Erik.