On Fri, 13 Feb 2004 12:07:45 -0000, sesummers wrote:

>--- In Firebird-Architect@yahoogroups.com, Jim Starkey <jas@n...>
>wrote:
>>snip<
>> both the existing scheme and something useable. Any thoughts on
>> requirements or ideas on an API would be appreciated.
>>
>> My personal feelings are that security information belongs in a
>> database, and that storing a SHA hash of passwords makes the most
>> sense. There are other secure hashes. Does anyone has strong
>>feelings on the subject?
>
>I'm in agreement with eumir_camara- I'd like to be able to put users
>and passwords into each database. But I want to allow them in the
>central file as well (which is necessary anyway to have users who can
>work with any database on that server and create new ones.)
>
>Even better would be the ability to declare to the database which
>table I'm putting my users in, and which fields are Name, Role and
>Password (optional- it would be fine if it were the first three.)
>Alternatively, I'd want to make it easy to add fields to
>the "official" user table. But the goal is to have one table where I
>can edit the list of users using the database, where I can associate
>them with related records as well as edit their passwords through my
>own code, using normal tools rather than API calls.

So, each database will have a user list with passwords?
I don't think is a good idea if you have more than one DB. I also
admin MSSQL and I like (besides the quircks) the user/login
coupling. So, all password/basic access right information is in one
place and more fine-grained info is given to the role (or individual
users) in the DB itself. This make roles/users db-wide but logins/pass/
rights to connect DB server-wide.It is AGT (A Good Thing).
Maybe some SQL commands or external stored procs can handle
the hassle of maintenance of users/logins/roles on DSQL environment.

>
>I would have the users in the database's local table have precidence
>over the users in the system's security table, so that if I don't
>have a "SYSDBA" user in my local table, the one in the system will
>work, but if I do, and the local one has a different password than
>the system's SYSDBA, then my database would be secured even if copied
>over to a different machine with its own SYSDBA.

And if the one that knows the SYSDBA pass die or go without notice
and you have to solve a "conflict of permissions"-like problems?
This exist in real world and could be a pain in the * to solve, while
if SYSDBA access all it is very easily.
Anyway, it could be done for embedded systems, which could be
configured to mirror security DB in it. But it is a "giving rope to
hang out"
feature.

>
>
>
>
>
>
>Yahoo! Groups Links
>
>
>
>
>