Alexandre Benson Smith wrote:

>Alex Peshkov wrote:
>
>
>
>>Si Carter wrote:
>>
>>
>>
>>
>>
>>>
>>>
>>>
>>>
>>>>-----Original Message-----
>>>>It's a question of control. With coteries you can let less
>>>>privileged
>>>>users come in from anywhere but restrict SYSDBA (or whatever) to
>>>>specific hosts or hosts strictly behind the firewall.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>This sounds like a good idea, and certainly one which enhances an RFE I
>>>added in January
>>>(http://sourceforge.net/tracker/index.php?func=detail&aid=1108195&group_id=9
>>>028&atid=359028). More and more web hosts are starting to allow customers
>>>to use FB, imo, a block at the firewall level is not a good solution, if
>>>your customers have dynamic ip at home/office and want to connect and their
>>>new IP is not in the list they can't get in. Allowing FB to control this
>>>would be a fantastic enhancement.
>>>
>>>
>>>
>>>
>>>
>>>
>>May be it's time to discuss details.
>>
>>1. In which form should coteries be kept? To allow access from network
>>192.168.3.0 known forms are at least:
>>192.168.3.0/24
>>192.168.3.0/255.255.255.0
>>192.168.3.0
>>192.168.3.
>>My prefered style is 1, but it's interesting to know other people's mind.
>>
>>2. How should be cotteries entered? Should we add switches to gbak?
>>Services API? Isc_user_* family of functions? (I know Jim will answer
>>that it's necessary to have fb_authenticate_user, but for fb2 this is
>>unreal suggestion).
>>
>>3. Do we let user have infinite number of coteries or limit it with some
>>reasonable thing? Answer is not very simple, if we want to let user
>>modify his coteries himself. If limited, should it be configurable or
>>hardcoded?
>>
>>
>>
>>
>Hi Alex,
>
>
>I prefer this:
>
>192.168.3.0/24
>
>or
>
>192.168.3.123
>
>for a full ip address
>
>How cotteries should be managed ?
>It will be per database ? per server ?
>
>

I think they should be stored in security database. That means for fb2.0
- per server. For vulcan - up to configuration.

>The data should reside insede the database ?
>

yes

>or should have some config file (cotteries.conf) ?
>

no-no-no

>Or will be just a field in the RDB$USERS ? or even a tbale RDB$COTTERIES that has a FK to RDB$USERS ?
>
>
>

This depends upon should we limit maximum number of coteries per user or
not. If yes, and this will be fixed unconfigurable numer, I prefer array
in RDB$USERS. In all other cases - separate table is needed.

>if it will be stored inside the database in system tables, users could update it as wish using simple SQL no need to an API call.
>
>
>

No - in firebird 2.0. Users can't access security database directly,
only via special API calls. This is first security barrier.
And then - how do you suppose will it look in GUI clients? Browse table
RDB$COTTERIES ? :)
If we want to implement feature, let's do it well.

I suggest to have additional spb_ parameters spb_add_cotery /
spb_remove_cotery, understandable during user modification
(spb_add_cotery also during user creation).
gsec should also have appropriate switches to add/remove cotery, but I
have no idea how should they be called.
Something like:
gsec mod username -cot_add 192.168.3.0/24
gsec mod username -cot_remove 192.168.3.0/24
but I'm sure better names exist.
isc_user_* family of API calls were deprecated in interbase 6, therefore
I suugest NOT to add coteries management to this ancient API.

Alex.