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

Re: Authentication in 1.3 (was Re: State of Perl-based database setup utilities for LedgerSMB 1.3)



On Sat, May 28, 2011 at 11:17 AM, David F. Skoll <..hidden..> wrote:
> On Sat, 28 May 2011 10:07:56 -0700
> Chris Travers <..hidden..> wrote:
>
>> 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.
>
> Really?

Yes.
>
> I was unaware of that.  I do not like that approach.  We run our LSMB
> 1.2 installation on a machine that says "local all all trust" in
> pg_hba.conf; no normal users have accounts on that machine.

The only way to give any real permissions enforcement in 1.2 (as
documented in the manual) is to create database users with appropriate
permissions and then use them for db users....

There's a significant amount of discussion on this matter in the
developer archives.  It might be worth reviewing this before reviving
this discussion.  It's also an issue that I don't see a reasonable way
to institute a permissions system against the old code.
>
> Making application users into database roles is a bad decision, IMO.
> It forces you to use PostgreSQL's auth mechanism which, while
> admittedly "mature and well-tested", might not be the most convenient
> way to manage users in the application.  I hope that you rethink this.
> It's a dealbreaker for me and means we can't use LSMB 1.3.

Sorry to hear that.  Given how difficult it would be to engineer real
security onto the SQL-Ledger code still in 1.3, I don't think there is
 way of doing this without delaying the release indefinitely.

Also trust authentication is documented as unsupported on 1.3.  There
ought to be some way around your configuration requirements, however.
You could allow MD5 authentication over the external ip address from
the same address (essentially a second loopback) and configure
LedgerSMB to connect to that IP address?  Or maybe set up a second
loopback on 127.0.0.0.2?  You don't have to connect over the same
interface that you have trust configured.

Best Wishes,
Chris Travers