[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

On Sat, 28 May 2011, Erik Huelsmann wrote:


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.
Do I understand correctly, that the current design, requires CLI level activity, in order to create users, add companies, and populate company databases (COA, etc.)? 
If not CLI, then some sort of PostGreSQL web frontend?
If that is so, is it also correct that no intent exists to integrate these operations into a web interface, such as 1.2's admin.pl, because doing so would require a PG admin user and admin database to exist, which we no longer want?
If so, the question has to be asked: what is the target audience for this application? 

 > 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.
but is that the fault of the mechanism, or of the application's notion of acceptable filesystem utilization? Because it sounds like you are faulting the latter, but excluding the former as a result.
(By which I mean that you are agreeing with Chris that the application should not get write access to one of its own configuration files; and then sighting as an example of why that's bad, an application that wants write access under /usr, instead of /var [where it should potentially have it].)
> 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
Do you only get one single issue queue [or analogous concept] from that action, or can you create more without running the package manager again? If you can, how is it done? 

 > first company database - created by packagers for specific

distributions.
Is the COA part of that first database, and do we still lock users into a COA template at company creation time? 


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.
Anyone who could crack you at that level, could presumably crack any other PGSQL user as well, and do the same kind of damage on a company by company basis.
I am not up on PGSQL permission granularity, but does the user which creates a user or database, necessarily have to retain the ability to delete it?
I am suggesting that you could handicap your admin user (we could provide a script for this), so that creations can be done by web interface using that admin user, but deletions would have to be done manually. 

Luke