--- In firebird-support@yahoogroups.com, "Ivo Santos Cavalcante
Carneiro" <iscc_listadisc@...> wrote:

>
> Hi all,
>
> I wanna 'listen' about your experience about applications security
> schema using Firebird. We support a medium-sized application that has
> based it's profile permissions on Firebird's roles. This model was
> developed without much tought, I must admit, and it's error prone -
> more then I would accept.
>
> I'm in charge of designing a new model, so I tought it would be wise
> to listen to other experienced developers about how the deal/dealt/are
> dealing with this issue.
>
> The present scheme uses Firebird's (SQL) default permission (select,
> insert, update, delete) on entities (relations), using roles to
> enforce it. Many operations, obviosly, must access a bunch of
> tables/procedures/views and this is very hard to mantain. Also,
> business rules demand control over not only 'full' entities, but over
> some fields too - who may change this or that field, etc. .
>
> I'd like to keep these rules defined on the database; I mean, use
> Firebird's security functions to ensure ACL's, so it make me feels
> like this could improve security a little. At least, prevent
> unauthorized operations even if a user tries direct access to
> database, bypassing the interface. OTOH, this may be a cumbersome
> work, and it may not be worth/possible. Surelly, I could leave
> everything to the interface...
>
> So, this is it. If some of you could share your experience, I'd be
> glad to 'listen' :-)
> It may be in private, case some of you don't wanna bloat the list or
> even if the moderator think this may be an OT topic.
>
> Some of my initials tought follows - initial, more like a 'brainstorm
> section', shapeless ideas...
>
> 1. I was thinking about something like an 'universal ID', that should
> identify uniquely each record on an database. Is there something like
> this? If so, is it safe to use - portable across backup/restore
> operations, for example? Thinking a filed like an record on db's
> catalog, this may led to some place...
>
>
>
> TIA,
> Ivo
>
> P.S.: I've made some effort to write well, but I'm not this expert in
> english, it's not my native language. Forgive anything, ok? :-)
>

Hi Ivo,
As you correctly figured, to mantain real security in a database means
to grant proper individual rights to each table, stored procedure or
trigger, and this may be a real pain. But I think it is the only way
of doing this right in a thin client applications environment. And I
hope to hear others opinion about that if I'm not right.
If we discuss here database modeling issues to implement any kind of
security model will be a long and off topic debate for sure. Let's do
it in private.

Regards,
Doru

PS: For user rights management we made and use a custom tool that we
will glad to share to the community : until this will be possible
(needs translation and docs) please contact me directly (you or whom
else may be interested) to help you solve this issue fast and easy.