Discussion :

[Artemus24]

Salut à tous.

J'utilise essentiellement FireBird version 4.0.2 au travers de script ISQL non interactif.
Je suis sous Windows 10 Pro.

J'ai voulu changer le mot de passe de sysdba et c'est là que je découvre que la sécurité ne fonctionne pas du tout.
Que je mette n'importe quoi comme mot de passe ou rien du tout, je peux quand même me connecter à ma base de données.
Voici mon script batch windows :

Code batch :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
@echo off
chcp 1252 > nul
 
SET FIC=%~nx0
SET FIC=%FIC:bat=sql%
 
CD %CD%
 
isql  -input "%FIC%"  -charset win1252  -echo  -password ''  -quiet  -role RDB$ADMIN  -user 'sysdba'  'MyDB'
 
@echo.
pause
exit

Comme on peut le voir, je n'ai pas renseigné mon mot de passe 'masterkey' et pourtant j'accède bien à la base de données 'MyDB'.
J'ai fait le même test avec un autre compte administrateur sur une autre base de données et j'ai le même problème.
Tout se passe comme s'il n'y avait pas de vérification par le mot de passe (password), mais uniquement sur le compte (user).

Inversement, en utilisant les accès par PDO sous php dans un site web, je ne rencontre par ce problème d'identification par mot de passe.
Je suppose que j'ai dû oublier de paramétrer quelque chose quelque part, mais je ne sais pas quoi.
J'ai fait mumuse aujourd'hui avec le fichier firebird.conf, mais je n'ai rien trouvé pour résoudre mon problème.

Savez-vous comment résoudre ce problème ?

Cordialement.
Artemus24.
@+

[Artemus24]

Salut à tous.

Voici un résumé des tests de sécurités que j'ai pu entreprendre sur FireBird.

a) Isql ne tient pas compte du mot de passe spécifié en ligne de commande.
Que je le précise, ou pas, que je mette un mot de passe qui n'existe pas, je peux quand même me connecter.
En lisant la documentation FireBird, je découvre que : "La version intégrée du serveur n'utilise pas l'authentification. Cependant, le nom d'utilisateur et, si nécessaire, le rôle doivent être spécifiés dans les paramètres de connexion, car ils contrôlent l'accès aux objets de la base de données".
J'ai un problème de sécurité que je ne sais pas résoudre.
A mon niveau, c'est pas bien grave car je ne fais que des tests et je n'ai rien de critique.

b) J'ai vérifié les accès aux bases de données FireBird à partir de mon site web.
Je développe en Php et j'utilise pour me connecter PDO.

Code php :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
<?php
/*-----------------------------------------------------*/
/* Informations pour la connexion à la base de données */
/*-----------------------------------------------------*/

$nom_du_serveur  = "firebird:dbname=127.0.0.1/3050:employee;";
$nom_utilisateur = "sysdba";
$mot_de_passe    = "masterkey";

$options         = array(PDO::ATTR_ERRMODE => PDO::ERRMODE_EXCEPTION);

/*----------------------*/
/* Connexion au Serveur */
/*----------------------*/

try {
	$link = new PDO($nom_du_serveur,$nom_utilisateur,$mot_de_passe,$options);
}
catch (Exception $e)
{
	echo "<br>Connection à FireBird impossible : ", htmlentities($e->getMessage());
	die();
}
?>

b-1) Le mot "employee" est celui déclaré dans le fichier "databases.conf" et correspond à l'alias de la base de données "Employee".
Je ne donne pas le chemin d'accès à la base et le développeur, ainsi que l'utilisateur ne sont pas censés savoir où elle se trouve.

b-2) L'identification par le compte (user) fonctionne ainsi que par le mot de passe (password).
J'ai modifié le mot de passe et j'ai constaté que je n'avais plus l'accès.
De même, si je désactive le compte 'sysdba', je n'ai plus l'accès aussi.
Ce niveau de sécurité fonctionne correctement.

b-3) les utilisateurs doivent avoir accès qu'aux applications au travers du site web.
Ils ne doivent pas avoir accès au fichier physique de la base de données.
On passe par l'alias et non par le chemin absolue vers le fichier physique de la base de données.

c) J'ai configuré mon fichier "databases.conf", que voici :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
# ----------------------- #
# List of known databases #
# ----------------------- #
 
Security = $(dir_secDb)/security4.fdb
{
	DefaultDbCachePages = 256
	RemoteAccess        = False
}
 
Employee = $(dir_sampleDb)/employee.fdb
{
	DefaultDbCachePages = 256
	RemoteAccess        = True
	SecurityDatabase    = Security
}
 
Base = E:/31.FireBird/02.DataBase/Base.fdb
{
	DefaultDbCachePages = 256
	RemoteAccess        = False
	SecurityDatabase    = Base
}

c-1) la sécurité de ma base de données 'Base' se trouve à l'intérieur de celle-ci.
J'ai créé 'base' en utilisant un compte propriétaire, autre que 'sysdba'.

c-2) la base de données 'Employee' utilise la sécurité qui lui est extérieur (fichier "security4.fbd").

c-3) La base de données "Security" n'est pas accessible par mon site web.
C'est le paramètre "RemoteAccess" du fichier databases.conf qui le dit.

d) J'ai configuré mon fichier "firebird.conf, que voici :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
# --------------------------------------- #
# Firebird version 4.0 configuration file #
# --------------------------------------- #
 
AuthClient         = Srp
AuthServer         = Srp
## DatabaseAccess     = FULL
## DatabaseAccess     = None
DatabaseAccess     = Restrict E:\31.FireBird\02.DataBase\Base.fdb
ExternalFileAccess = Full
RemoteAccess       = False
RemoteServicePort  = 3050
ServerMode         = Super
UserManager        = Srp
WireCrypt          = Enabled

Je me suis intéressé à "DatabaseAccess". Trois cas se présentent :

d-1) si la base de données existe déjà, on peut mettre "DatabaseAccess = None".
On peut la détruire, mais pas la recréer.
Le chemin d'accès à la base de données est celui de l'alias.
Les seules bases de données accessibles sont celles créées par les alias.

d-2) si la base n'existe pas, on peut met "DatabaseAccess = Restrict E:\31.FireBird\02.DataBase\Base.fdb".
On peut créer la nouvelle base de données "Base.fdb".
Les accès doivent se faire obligatoirement pas l'alias.
Les seules bases de données accessibles sont celles créées par les alias.
J'utilise cette méthode car je ne fais que des tests et donc je recrée la base à chaque fois.

d-3) La valeur par défaut est "DatabaseAccess = FULL".
Aucune restriction. L'accès par les alias n'est pas obligatoire.
On peut créer une base de données en précisant un chemin absolue.

Il est possible qu'il me manque des paramètres importants dans FireBird.

e) Comment sécuriser le SGBDR FireBird ?
e-1) mettre le SGBDR dans un répertoire du serveur qui n'est accessible que par le DBA.
Aucun utilisateur ne doit avoir un quelconque accès physique, même en lecture, au SGBDR FireWire.

e-2) mettre la base de données dans un répertoire qui n'est accessible que par le SGBDR FireBird.
De préférence dans un autre répertoire que celui du SGBDR FireBird.
Les bases de données ne doivent pas être accessibles physiquement par les utilisateurs.

e-3) tous les accès doivent se faire par les alias.
Cela implique de rendre le fichier "databases.conf" inaccessible par tous les utilisateurs, sauf le dba bien sûr.
Pareil pour le fichier "firebird.conf".

e-4) comme la base de données existe, mettre "DatabaseAccess = None" dans le fichier "FireBird.conf".
Voir ci-dessus.

f) l'astuce concernant le compte "sysdba" qui fonctionne sous FireBird 3.0, ne fonctionne plus dans la version 4.0.2 de FireBird :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
create role sysdba;
Statement failed, SQLSTATE = 28000
unsuccessful metadata update
-CREATE ROLE SYSDBA failed
-user name SYSDBA could not be used for SQL role
After line 9 in file 02.Users.sql

Il semble que ce bug dans FireBird 3.0 a été corrigé dans Firebird 4.0.

g) restreindre les accès aux seuls comptes activés dans la base de données FireBird.
g-1) j'utilise pour cela, le déclencheur suivant :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
create exception interdit 'You have no rights to view and modify the database !';
commit;
SET TERM #;
 
create trigger autorisation
on connect as
  declare variable flag smallint default null;
begin
  if (current_user = 'ARTEMUS') then exit;
 
  select 1 from PLG$SRP where PLG$USER_NAME = current_user and PLG$ACTIVE = true into flag;
  if (flag is null) then exception interdit;
end#
 
SET TERM ;#

Le compte "sysdba" n'existe pas dans ma base de données.

g-2) et pourtant, on peut quand même accéder au contenu de la base de données avec isql :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

isql  -input %FIC%  -charset win1252  -echo  -nodbtriggers  -password 'masterkey'  -quiet  -role 'rdb$admin'  -user 'sysdba'  'Base'

Cela permet de désactiver le déclencheur et d'entrer dans la base de données avec le compte "sysdba".

g-3) J'ai même créé le compte "sysdba" et je l'ai rendu inactif.
Mais rien n'y fait, l'accès reste quand même possible.
C'est le deuxième problème sécuritaire de FireBird.

g-4) je pensais que ce compte "sysdba" était celui présent dans "securite4.fdb"
J'ai désactivé ce compte, mais rien n'y fait.
J'ai supprimé le compte en recréant le fichier "securité4.fdb" à partir de "security4.fdb.empty", mais le problème persiste.
J'ai carrément supprimé le fichier "security4.fdb" et j'ai encore accès par l'astuce g-2).


Conclusion.
-----------
J'avais, il y a déjà quelque temps, fait une étude sur la sécurité de FireBid, sur la gestion des permissions.
J'avais crée cinq utilisateurs qui sont :
--> Artemus : le propriétaire et créateur de la base de données.
--> Ulysses : un super utilisateur ayant tous les droits sans être administrateur.
--> Jeremy : un utilisateur ayant les droits de manipulation sur les tables.
--> James : un utilisateur ayant le droit que de lire la table test.
--> Miguelito : un utilisateur qui n'a aucun accès.
Les tests m'ont permis de comprendre comment configurer ces privilèges.

J'ai poursuivi mes investigations sur le niveau sécuritaire de FireBird.
Et je constate qu'il y a plusieurs problèmes de sécurités :
--> sous isql, le mot de passe n'est pas utilisé pour s'authentifier.
--> sous isql, même si le compte "sysdba" n'est pas présent dans la base de données, on peut quand même se connecter.
--> j'utilise un déclencheur pour contrôler les accès. Dans isql, si on met "-nodbtriggers", on peut désactiver les contrôles d'accès.

Pour contourner ces problèmes :
--> ne pas rendre accessible physiquement les fichiers physiques des bases de données.
--> protéger le SGBDR FireBird en le rendant inaccessible aux utilisateurs.
--> ne pas, non plus, rendre les alias accessibles aux utilisateurs.
--> tous les accès doivent se faire par une application web.
--> ne pas utilisez le compte sysdba dans la base de données.
--> fusionner la base de sécurité et la base des données.

Cordialement.
Artemus24.
@+

[devalender]

Comme on peut le voir, je n'ai pas renseigné mon mot de passe 'masterkey' et pourtant j'accède bien à la base de données 'MyDB'.
J'ai fait le même test avec un autre compte administrateur sur une autre base de données et j'ai le même problème.
Tout se passe comme s'il n'y avait pas de vérification par le mot de passe (password), mais uniquement sur le compte (user).

Inversement, en utilisant les accès par PDO sous php dans un site web, je ne rencontre par ce problème d'identification par mot de passe.
Je suppose que j'ai dû oublier de paramétrer quelque chose quelque part, mais je ne sais pas quoi.
J'ai fait mumuse aujourd'hui avec le fichier firebird.conf, mais je n'ai rien trouvé pour résoudre mon problème.

Savez-vous comment résoudre ce problème ?

Cordialement.
Artemus24.
@+

Bonjour Artemus24

Je viens de lire avec beaucoup d'attention, la première partie de ton post. J'ai la version 3.xx de Firebird, je confirme ce que tu as constaté :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
 
C:\Program Files\Firebird>cd firebird_3_0
C:\Program Files\Firebird\Firebird_3_0>isql.exe
Use CONNECT or CREATE DATABASE to specify a database
SQL> connect "C:\COREWIN\COREWIN_BASE2022.FDB"
CON> user 'SYSDBA' password '' ;
Database: "C:\COREWIN\COREWIN_BASE2022.FDB", User: SYSDBA
SQL>

Sans mot de passe la connexion passe !

je continue de lire la deuxième partie du post.

[devalender]

J'ai poursuivi mes investigations sur le niveau sécuritaire de FireBird.
Et je constate qu'il y a plusieurs problèmes de sécurités :
--> sous isql, le mot de passe n'est pas utilisé pour s'authentifier.
--> sous isql, même si le compte "sysdba" n'est pas présent dans la base de données, on peut quand même se connecter.
--> j'utilise un déclencheur pour contrôler les accès. Dans isql, si on met "-nodbtriggers", on peut désactiver les contrôles d'accès.

Pour contourner ces problèmes :
--> ne pas rendre accessible physiquement les fichiers physiques des bases de données.
--> protéger le SGBDR FireBird en le rendant inaccessible aux utilisateurs.
--> ne pas, non plus, rendre les alias accessibles aux utilisateurs.
--> tous les accès doivent se faire par une application web.
--> ne pas utilisez le compte sysdba dans la base de données.
--> fusionner la base de sécurité et la base des données.

Cordialement.
Artemus24.
@+

Merci pour toutes ces indications, dans la pratique comment on réalise le point 2 au niveau du contournement des problèmes ?

[Artemus24]

Salut Devalender.

Merci à toi de t'intéresser à la sécurité du SGBDR FireBird.

Sans mot de passe la connexion passe !

Tu n'as même pas besoin de préciser le mot de passe, il te suffit d'écrire :

Code firebird :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
c:\>isql
Use CONNECT or CREATE DATABASE to specify a database
SQL> connect base user sysdba;
Database: base, User: SYSDBA
SQL>

et ça passe sans problème ! Base est l'alias de l'une de mes base de données.

Merci pour toutes ces indications, dans la pratique comment on réalise le point 2 au niveau du contournement des problèmes ?

Pour le point 2, je parlais des privilèges attribués aux utilisateurs dans la base de données.
Ces utilisateurs doivent impérativement passer par le SGBDR FireBird pour accéder à la base de données.
En dehors de l'application qui accède à FireBird et à la base de données, ces utilisateurs n'ont aucun accès.

Sous Windows, j'ai modifié mon PATH afin d'avoir accès à FireBird n'importe où dans mon ordinateur.
Ceci est un point de la sécurité à ne pas négliger car cela rend la base accessible par les alias.

Pour les privilèges, il faut classifier tes utilisateurs en fonction de ce qu'ils ont droits de faire.
Cela demande une authentification lors de la connexion à l'application.
Ainsi que d'avoir confiance dans ces utilisateurs qui auront certains privilèges.

Le problème concerne les accès aux données sensible, comme la paye.
L'idée est de créer des groupes et un chef de groupe comme dans la gestion d'un forum.
Le chef du groupe a la possibilité de créer un nouveau membre dans son groupe, voire aussi de le supprimer.
Mais il n'aura pas la possibilité de modifier les privilèges de son groupe.

Si un nouveau groupe doit être créé, ayant d'autres privilèges, qui devra le faire ?
Dans un forum, c'est le rôle de l'administrateur. Qui va jouer ce rôle ?

Le DBA ? Comme celui-ci à un accès physique à la base de données, il peut tout faire, mais est-ce son rôle ?
Un DBA ne devrait pas avoir accès à des données sensibles, car il n'est pas habilité à les lire.

Un membre particulier appartenant au groupe administrateur ayant plus de privilèges que les autres groupes ?
Tout repose sur la confiance en cette personne pour l'attribution de nouveaux privilèges.

De même, dans les forums, il y a des modérateurs qui font de la surveillance.
Il faudra aussi créer un groupe spécial pour surveiller.
Cela implique de créer des outils afin de savoir qui se connecte et qu'est-ce qu'il fait.

Devalender, si tu as des idées pour améliorer la sécurité de FireBird, je suis preneur.

Cordialement.
Artemus24.
@+

[SergioMaster]

Bonjour,

J'avais lu les posts, mais pris par le temps, pas répondu.
Je pense qu'il y a un facteur qui n'a pas été pris en compte dans ce constat, le fait que ISQL peut travailler avec le moteur firebird embedded qui lui n'utilise pas la base de sécurité.

Il faudrait faire un test isql avec une bdd sur un autre serveur ou peut-être avec un autre protocole d'accès serverxyz[/port]:C:\Program Files\Firebird\examples\employee.fdb

n'oublions pas non plus que les variables d'environnement peuvent exister, ce qui fausserait l'étude

[Artemus24]

Salut à tous.

Je suis toujours en ligne de commande avec "ISQL" et je n'arrive pas bien à configurer FireBird.

Je vous communique mon fichier Databases.conf que voici :

Code firebird :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
# ------------------------- #
#  List of known databases  #
# ------------------------- #
 
Security = E:/31.FireBird/02.DataBase/Security4.fdb
{
	DefaultDbCachePages = 2048
	RemoteAccess        = True
}
 
Employee = E:/31.FireBird/02.DataBase/Employee.fdb
{
	DefaultDbCachePages = 2048
	RemoteAccess        = True
	SecurityDatabase    = Security
}
 
Base = E:/31.FireBird/02.DataBase/Base.fdb
{
	DefaultDbCachePages = 2048
	RemoteAccess        = True
	SecurityDatabase    = Base
}

Ainsi que mon fichier de configuration Firebird.conf :

Code firebird :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
# ----------------------------------------- #
#  Firebird version 4.0 configuration file  #
# ----------------------------------------- #
 
AuthClient         = Srp
AuthServer         = Srp
## DatabaseAccess     = FULL
## DatabaseAccess     = None
DatabaseAccess     = Restrict E:/31.FireBird/02.DataBase
ExternalFileAccess = Full
## Providers          = Remote, Loopback
RemoteAccess       = False
RemoteServicePort  = 3050
SecurityDatabase   = E:/31.FireBird/02.DataBase/Security4.fdb
ServerMode         = Super
UserManager        = Srp
WireCrypt          = Disabled

Toutes mes bases de données sont dans le même répertoire : "E:/31.FireBird/02.DataBase".

J'ai recopié la base de sécurité "Security4.fdb" dans mon environnement, ainsi que la base 'Employee'.
La sécurité de 'Employee' est gérée par 'Security'.
La sécurité de 'Base' est gérée par 'Base'.
(Voir le fichier Databases.conf)

Je connaissais déjà le préfixe "localhost/3050:" puisque je l'utilise dans mon site Web.
Je préfixe mes chemins par "localhost/3050:" sous isql, ainsi que sous mon site Web.

a) les accès où je ne suis pas obligé de préciser le préfixe sont accessible sans mot de passe. C'est le "Firebird Embedded".
Il y a un paramètre qui gère cela "Engine13", sauf que cela ne fonctionne pas chez moi (FireBird 4) :

Code firebird :

Sélectionner tout - Visualiser dans une fenêtre à part

Providers = Remote, Engine13, Loopback

A mettre dans me fichier "Firebord.conf".

Si je supprime "Engine13" puisque c'est lui qui gère les accès en direct (sans mot de passe), je n'ai plus aucun accès à mes bases.

b) j'ai voulu m'authentifier par mon compte windows.
Là aussi, ca ne fonctionne pas où alors je ne sais pas comment m'y prendre.
Il me semble que le plugin "Win_Sspi" ne soit pas opérationnel.

J'ai une erreur en faisans ceci :

Code FireBird :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
Use CONNECT or CREATE DATABASE to specify a database
SQL> connect xnet://base;
Statement failed, SQLSTATE = 28000
Missing security context for base
SQL>

Mais ca fonctionne sur 'Employee' :

Code firebird :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
Use CONNECT or CREATE DATABASE to specify a database
SQL> connect employee;
Database: employee, User: PATRON
SQL>

Le compte Patron est celui de windows et non de FireBird.

Si je tente de créer le compte patron :

Code firebird :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
create user patron password 'patron' firstname 'Patron' lastname 'Boss' grant admin role active using plugin win_sspi;
Statement failed, SQLSTATE = 28000
User management plugin is missing or failed to load

cela ne fonctionne pas comme si le plugin "Win_Sspi" n'était pas présent.

c) j'ai fait le test d'accès sur 'Base' :

Code firebird :

Sélectionner tout - Visualiser dans une fenêtre à part

isql  -input %SQL%  -charset win1252  -echo  -password 'artemus'  -quiet  -role RDB$ADMIN  -user artemus  localhost/3050:E:/31.FireBird/02.DataBase/Base.fdb

Cette base contient les données ainsi que la sécurité. elle diffère dans son fonctionnement de 'Employee'.
J'ai cette erreur :

Code FireBird :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
Statement failed, SQLSTATE = 08006
Error occurred during login, please check server firebird.log for details
After line 0 in file 01.Test.sql
show database;
Command error: show database
exit;

Je vérifie dans mon "firebird.log" :

Code FireBird :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
ORION	Sun Jun  4 17:38:43 2023
	Authentication error
	exception 1
	FORBIDDEN
	You have no rights to view and modify the database !
	At trigger 'AUTORISATION' line: 8, col: 26

Mon déclencheur "autorisation" filtre les accès.

Je ne comprends pas pourquoi je ne suis pas autorisé alors que j'ai le bon compte firebird et le bon mot de passe.
Si je désactive le déclencheur, j'entre dans ma base de données.
Je ne comprends pourquoi j'ai cette erreur.

d) j'ai quelques erreurs qui surviennent de temps en temps :

Code firebird :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
 
ORION	Sun Jun  4 23:43:43 2023
	MappingIpc: Cannot initialize the shared memory region
	Shared memory area is probably already created by another engine instance in another Windows session

Je n'ai qu'une seule instance de FireBird en mode "Super".

Ce sont ces points que je désire résoudre.

Cordialement.
Artemus24.
@+

[SergioMaster]

Bonjour,

Il y avait donc bien une histoire de "Firebird Embedded" non prise en compte dans les posts du début. Je suis content d'avoir posé le bon diagnostic.
Par contre, pour ce qui est du provider à désactiver, j'ai un doute, j'aurais plutôt parié sur loopback, je ferais des recherches en cours de journée :

1. Providers
2. Configuration d'une base de sécurité embarquée

Deux points que je maitrise mal, il va me falloir relire les deux guides de migrations

[Artemus24]

Salut SergioMaster.

Merci de t'investir dans ce genre de problème que je maitrise mal aussi. La documentation est très mal foutue.
Pour trouver les bonnes informations il faut beaucoup chercher sans nécessairement trouver les réponses.

Je désire obtenir les points suivants dans l'usage de FireBird avec l'outil "ISQL" :

a) un utilisateur qui ne donne pas son mot de passe ou si celui-ci n'est pas le bon, il doit être rejeté.
Cela fonctionne si tu précises le préfixe : "localhost/3050:".
C'est ce que j'ai fait dans mes accès avec mon site Web.

Sous "ISQL", ca fonctionne sauf que l'utilisateur peut ne pas l'indiquer.
Si tu ne précises pas le préfixe, l'accès se fait sans authentification par le mot de passe et ça, je ne le veux pas.
Il parait que c'est l'accès normal sous FireBird Embedded.

b) comment désactiver FireBird Embedded ?
Il me semble que cela concerne le paramètre Providers de "FireBire.conf" mais je n'en suis pas sûr.
Je l'ai testé mais ca ne fonctionne pas. Il doit me manquer quelque chose, mais quoi ?

c) entrer dans FireBird avec le compte Windows. J'ai fait le test de :

Code firebird :

Sélectionner tout - Visualiser dans une fenêtre à part

CREATE GLOBAL MAPPING TRUSTED_AUTH USING PLUGIN WIN_SSPI FROM ANY USER TO USER;

La ligne a bien été prise mais je n'ai pas pu créer un compte avec le plugin "WIN_SSPI".

d) dans ma base 'Base', j'ai placé la sécurité et j'ai mis un déclencheur lors de la connexion.
Tout ce passe comme si je n'avais pas le bon compte et le bon mot de passe.
Je suis rejeté par mon déclencheur "autorisation" comme on peut le voir dans mon message précédent.
Si maintenant, je modifie le fichier de sécurité dans "databases.conf", l'accès se fait correctement.
Dans les deux cas, j'accède par le même compte et le même mot de passe.
Là aussi, je ne comprends pas le rejet.

Merci SergioMaster de t'investir dans ce genre de problème.

Cordialement.
Artemus24.
@+

[Artemus24]

Salut à tous.

J'essaye de résoudre mon problème d), sans succès.

Si je mets dans mon chemin uniquement l'alias "Base", j'ai bien l'accès avec le bon compte utilisateur.
Sauf que j'obtiens l'authentification sans préciser mon mot de passe, ce que je ne veux pas.

Si mon chemin devient "localhost/3050:Base", je ne sais pas pourquoi, FireBird me force le compte à "Sysdba".
D'où l'interdiction que j'ai pour accéder à ma base de données.
Cette interdiction est voulue car je veux entrer dans ma base "Base" avec le bon compte et le bon mot de passe.

Si j'ai bien compris le fonctionnement de FireBird, avec seulement l'alias, la connexion se fait en mode intégré.
Si je précise le préfixe, donc l'hôte et le port, la connexion se fait en mode réseau.

Voici mon batch Windows :

Code batch :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
@echo off
chcp 1252>nul
 
set   SQL=01.Test.sql
set ALIAS=localhost/3050:Base
 
set isc_user=artemus
set isc_password=artemus
 
cd %CD%
 
cls
@echo Accès par l'Alias 'MyDB' SANS mot de passe
@echo ------------------------------------------
@echo.
 
isql  -input %SQL%  -charset win1252  -echo  -password ''  -quiet  -user jeremy  %ALIAS%
 
@echo.
pause
exit

Mon compte est "jeremy". J'ai fait exprès de ne pas mettre de mot de passe. En principe, l'accès ne doit pas se faire.
Le chemin est "localhost/3050:Base". Autrement dit, j'ai une connexion réseau et non locale.
Voici le contenu du fichier "FireBird.log" :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
 
ORION	Mon Jun  5 19:50:11 2023
	Authentication error
	exception 1
	FORBIDDEN
	"SYSDBA" have no rights to view and modify the database !
	At trigger 'AUTORISATION' line: 9, col: 24

La connexion a pu se faire sur la base "Base".
Mais elle s'est faire avec le compte "Sydba" et non comme je l'ai demandé par "Jeremy".
Comme le compte "Sysdba" n'est pas autorisé, mon déclencheur l'a rejeté et c'est normal.

Pourquoi FireBird m'impose ce compte "Sydba" ?
D'où sort ce compte "sysdba" puisque je ne l'ai pas précisé dans mon batch Windows ?

Cordialement.
Artemus24.
@+

[Artemus24]

Récapitulatif :

a) dans Databases.conf, pour l'alias 'Base', je mets "databaseaccess = Base".
(La sécurité est dans la base de données 'Base')

a-1) par le chemin "Base" : l'accès est correct.
Le mot de passe n'est pas vérifié, ce que je ne veux pas.

a-2) par le chemin "localhost/3050:Base": l'accès se fait.
Je ne peux pas utiliser mon compte car FireBird le force à "Sysdba".
Comment désactiver cette contrainte


b) dans Databases.conf, pour l'alias 'Base', je mets "databaseaccess = Security".
(La sécurité est extérieure à la base de données 'Base', ce que je ne veux pas.)

b-1) par le chemin "Base" : l'accès se fait.
C'est pareil que a-1).

b-2) par le chemin "localhost/3050:Base": l'accès est correct.
Je peux utiliser mon compte, il y a bien authentification par le mot de passe.
Si la sécurité est extérieure FireBird fonctionne correctement.
Sauf que je veux la sécurité intérieure à la base de données.

Dans a) et dans b), j'utilise le même compte et le même mot de passe.


c) sous mon site Web, j'ai exactement les mêmes problèmes.


d) avec FireBird, je cherche à :

d-1) mettre la sécurité dans la base de données et non à l'extérieur dans security4.fdb.
FireBird fonctionne correctement si la sécurité est extérieure à la base de données.

d-2) accéder à la base de données avec mes comptes et non par le compte "Sysdba".
Avec un accès par le chemin "localhost/3050:Base", FireBird force le compte à "Sysdba" si la sécurité est intérieure.
Il semble que c'est un bug !

d-3) authentifier l'accès par le mot de passe. Cela fonctionne que si le chemin "localhost/3050:Base est utilisé.

d-4) interdire l'accès au compte "Sysdba", sauf que ce n'est pas possible.
On peut contourner le problème :
--> soit en utilisant "-nodbtriggers" pour désactiver le déclencheur qui gère la connexion.
--> soit en créant un compte admin "sysdba" dans "security4.fdb" et en modifiant "databaseaccess = Security".

Dans FireBird 4.0, on ne peux plus créer un rôle de nom "sysdba".
On ne peux pas désactiver le compte "Sysda" qui a tous les droits dans FireBird.


e) si l'on met "DatabaseAccess = None", les seul accès se font que par l'alias, ce qui est bien.
Si l'on est connecté, en faisant :

Code firebird :

Sélectionner tout - Visualiser dans une fenêtre à part

select MON$DATABASE_NAME from mon$database;

on découvre l'alias, sinon nous avons le chemin vers l'emplacement physique de la base de données.
Les utilisateurs n'ont pas besoin de connaitre le chemin pour accéder à la base.


Conclusion

Je ne peux pas avoir la sécurité dans la base de données et c'est bien dommage.

Cordialement.
Artemus24.
@+

[SergioMaster]

Bonjour,

je réponds à la question "embedded" par quelques extraits des guides de migration de Carlos H Cantu

The firebird.conf file has a list of providers in the following order: Remote, Engine13 (embedded) and loopback. When Firebird receive a connection request using the string above, it runs through the list of providers, from left to right, until it finds a provider that recognizes and creates the connection.
In this example, the first provider (Remote) fails since there is no host name in the string. The connection request then goes to the second provider (Engine13), which establishes an embedded connection.
How do you make an xnet connection rather than an embedded connection? To do so, you must specify the xnet protocol in the connection string:
xnet://c:\databases\base.fdb

You might ask why you would want to use xnet instead of embedded for a local connection. One possible scenario is that Firebird is running as SuperServer with an active connection to that database. In that case, the embedded connection to the database fails because the SuperServer has the database file open in exclusive mode. However, the xnet connection works since it will connect through the running SuperServer.

In isql, the show version command is an easy way to determine what kind of connection has been established:
SQL>show version;
Firebird/Windows/Intel/i386 (remote server), version " WI-V4.0.0.2496 Firebird 4.0/tcp (servidor)/P16:C"
SQL>show version;
Firebird/Windows/Intel/i386 (remote server), version " WI-V4.0.0.2496 Firebird 4.0/XNet (servidor)/P16"
Another way to show the connection type is to read the MON$REMOTE_PROTOCOL field of the mon$attachments monitoring table.

Lorsque j'ai commencé à regarder comment initialiser une base de sécurité, une phrase a retenu mon attention

Make sure that Firebird 3 process is not running so you will connect to employee.fdb in embedded mode.

[Artemus24]

Salut à tous

a) Ma base 'Base' contient à la fois les données et la sécurité.
J'utilise le déclencheur de SergioMaster qui filtre les comptes et entre autre 'Sysdba' que je rejette.
(voir en fin de ce message le déclencheur.)

Le premier accès se fait avec le compte 'Sysdba'. Je ne sais pas pourquoi FireBird fonctionne ainsi.
Et celui-ci accède à la base avant l'accès au compte 'Artemus', celui par lequel je désire me connecter.
De ce fait, puisque je rejette 'sysdba', je ne peux plus accéder à ma base avec n'importe quel compte qui est autorisé.

Ce qui implique que je ne peux plus filtrer sur le compte 'sysdba' sinon, c'est bloquant.
Dans mon déclencheur, je ne filtre plus l'utilisateur "sysdba".

b) pour interdire l'accès à la base 'Base' au compte 'Sysdba', il suffit de le créer en "inactive".
L'astuce qui consistait à utiliser le paramètre "-nodbtriggers" dans la ligne "isql" pour désactiver le déclencheur n'a plus aucun intérêt.
L'autre astuce de la version FireBird 3.0 qui consistait à créer un rôle de nom "Sysdba" ne fonctionne plus dans FireBird 4.0.

c) pour accéder à ma base, j'utilise plusieurs chemin dont :
--> l'alias "Base",
--> le chemin complet "E:/31.FireBird/02.DataBase/Base.fdb".
--> par l'adresse ip "localhost/3050:Base".
--> la forme que je vais utiliser "xnet://localhost/3050:Base".

Selon le chemin, je n'ai pas les mêmes comportements, dont entre autre aucune authentification par le mot de passe.
Ce comportement est celui de l'accès par "FireBird Embedded" en accès direct.

Je cherche soit à interdire l'authentification sans le mot de passe, ou bien interdire l'accès si je n'utilise pas le bon chemin.
(voir en fin de ce message le déclencheur.)

d) pour interdire l'accès par le chemin absolue, il faut utiliser le paramétre "DatabaseAccess = None" dans "FireBird.conf".
Sauf que cela ne peut pas me convenir car je peux détruire la base mais pas la recréer.
A cause de cela, je suis obligé de rester en "DatabaseAccess = Strict".

e) le mode "FireBird Embedded" est géré par le paramètre "Providers du fichier "FireBird.Conf".
Par défaut, le paramètre se présente ainsi :

Code firebird :

Sélectionner tout - Visualiser dans une fenêtre à part

#Providers = Remote,Engine13,Loopback

J'ai supprimé le commentaire "#" devant la ligne.
Et comme d'autres internaute, j'ai cru qu'en supprimant "Engine13", j'allais résoudre mon problème.
Si je supprime le moteur, je n'ai plus aucun accès à ma base car celui-ci gère le serveur FireBird.
On peut le faire que si l'on se trouve en client FireBird.
Maintenant, le mot de passe est vérifié.

f) le chemin normal, même en local, que je vais utilisé partout est : "xnet://localhost/3050:Base".
Si je désire accéder à l'un de mes comptes, j'ai cette erreur :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
ORION	Tue Jun  6 17:02:12 2023
	Authentication error
	Your user name and password are not defined. Ask your database administrator to set up a Firebird login.

Cela signifie que FireBird cherche le compte dans l'alias "Security" et non dans l'alias 'Base'.
C'est normal car dans le fichier "FireBird.conf", j'utilise l'alias de cette façon là : "SecurityDatabase = Security.
Ce qui m'oblige à créer les permissions dans "Security" et non dans "Base".

g) si j'ai une seule base de données, je peux regrouper les données et la sécurité dans la même base.
Je dois paramétrer dans "FireBird.conf" le paramètre à "SecurityDatabase = Base".
Et dans "Databases.conf", mettre le paramètre à "SecurityDatabase = Base" pour l'alias "Base".
Et je n'ai plus besoin de "Security4.fdb" que je peux détruire.

h) Le paramètre "SecurityDatabase = Base" de l'alias 'Base' du fichier "Databases.conf" n'est pas utilisé pour se connecter.
Systématiquement, la connexion se fait par le paramètre "SecurityDatabase" du fichier "FireBird.Conf".
Ce point me pose un problème de sécurité dont je ne sais pas comment le résoudre.

i) Si j'ai plusieurs base de données, je suis obligé d'extérioriser les permissions en les mettant dans "Security4.fdb".
Ce n'est pas gênant en soit si l'on fait le choix de centraliser la sécurité dans ce fichier.
Mais les déclaratives deviennent lourdes à mettre en œuvre quand un utilisateur n'a pas les mêmes droits selon la table et selon la base de données.

j) pour résoudre le problème de la mémoire partagée, j'ai changé le "ServerMode".
Avant, dans le fichier "FireBird.conf", j'avais "ServerMode = Super" et maintenant je suis en "ServerMode = Classic".
Maintenant, je n'ai plus le message d'erreur que j'ai indiqué dans un autre message de cette discussion.

Il parait aussi que "FireBird Embedded" disparait mais je ne l'ai pas constaté.

k) j'ai testé le mode d'authentification par le compte windows qui ne fonctionne que par l'alias.
Pour contrôler les chemins autorisés, je suis obligé de le faire lors de la connexion à la base. Voici mon déclencheurs :

Code firebird :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
SET TERM #;
 
create trigger autorisation
active on connect as
  DECLARE flag smallint default null;
begin
if (current_user = 'SYSDBA') then exit;
 
if (not exists (select 1 from PLG$SRP where PLG$USER_NAME = current_user and PLG$ACTIVE = true))
then exception FORBIDDEN using (current_user);
 
if (not exists (select 1 from MON$ATTACHMENTS where MON$ATTACHMENT_ID = CURRENT_CONNECTION and MON$AUTH_METHOD in ('Srp','OS user name')))
then exception METHOD using (current_user);
end#
 
SET TERM ;#

"OS user name" est la méthode de connexion par le compte Windows".
"Srp" est la méthode de connexion passant par le plugin "Srp".

Je n'ai trouvé que cette façon de faire pour contrôler les différents accès à ma base 'Base'.

l) à titre indicatif, voici mon fichier "FireBird.conf" pour ceux que cela intéresse :

Code firebird :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
# ----------------------------------------- #
#  Firebird version 4.0 configuration file  #
# ----------------------------------------- #
 
AuthClient         = Srp
AuthServer         = Srp
## DatabaseAccess     = FULL
## DatabaseAccess     = None
DatabaseAccess     = Restrict E:/31.FireBird/02.DataBase
ExternalFileAccess = Full
Providers          = Remote,Engine13,Loopback
RemoteAccess       = False
RemoteBindAddress  =
RemoteServicePort  = 3050
SecurityDatabase   = Security
ServerMode         = Classic
UserManager        = Srp
WireCrypt          = Enabled

m) voici mon fichier "Databases.conf" :

Code firebird :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
# ------------------------- #
#  List of known databases  #
# ------------------------- #
 
Security = E:/31.FireBird/02.DataBase/Security.fdb
{
	DefaultDbCachePages = 8K
	RemoteAccess        = False
}
 
Employee = E:/31.FireBird/02.DataBase/Employee.fdb
{
	DefaultDbCachePages = 32K
	RemoteAccess        = True
	SecurityDatabase    = Security
}
 
Base = E:/31.FireBird/02.DataBase/Base.fdb
{
	DefaultDbCachePages = 16K
	RemoteAccess        = True
	SecurityDatabase    = Base
}

conclusion :

J'ai résolu mon problème d'authentification par le mot de passe.
J'ai résolu aussi l'interdiction de l'accès à la base de données par le compte "Sysdba".
J'utilise maintenant les alias au lieu des chemins absolues.
J'utilise un filtrage pour interdire les mauvaises méthodes d'accès à la base.
Je pense même que l'on peut se débrouiller pour rendre inopérant la copie de la base de données.
Par exemple, en testant le nom du serveur (Host) où se trouve FireBird.

Je n'ai pas tout compris du "FireBird Embedded" et comment le désactiver.
Le point h) où j'aimerai lors d'une connexion que FireBird se serve des permissions dans la base 'Base' et non celle de "Security".

Cordialement.
Artemus24.
@+

[Artemus24]

Salut à tous.

J'ai fait quelques tests sur le point h).
L'alias de ma base de données est : 'Base'.
L'alias "Security" (Security4.fdb) est la sécurité de l'ensemble des accès à toutes mes bases.

Il me faut des explications sur ces protocoles.
La syntaxe est particulière, surtout en ce qui concerne les deux-points qui portent à confusion.
Dans l'ancienne syntaxe, les deux-points sont le séparateur du port et le slash, le séparateur de l'alias.
Dans la nouvelle syntaxe, c'est l'inverse.

--> inet://localhost:3050/Base (ancienne syntaxe)
--> inet://localhost/3050:Base (nouvelle syntaxe)

Mais le plus surprenant, les protocoles ne fonctionnent pas de la même façon.

Avec l'ancienne syntaxe, l'identification passe par l'alias 'Base' :
--> inet://192.168.1.20:3050/Base
--> wnet://192.168.1.20:3050/Base
fonctionnent mais par contre :
--> xnet://192.168.1.20:3050/Base
--> xnet://192.168.1.20/Base
ne fonctionnent pas.

Avec la nouvelle syntaxe, l'identification passe par l'alias 'Security' :
--> wnet://192.168.1.20/3050:Base
--> xnet://192.168.1.20/3050:Base
fonctionnent mais par contre :
--> inet://192.168.1.20/3050:Base
--> inet://192.168.1.20:Base
ne fonctionnent pas.

Pourquoi cette différence dans la façon de s'identifier ?

Si l'on utilise le protocole "INET", le mieux est d'utiliser l'ancienne syntaxe.

Cordialement.
Artemus24.
@+