Re: [Firebird-devel] Ability to use non-local protocol to create DB which alias is declared as self-security

2022-08-10 Thread Alex Peshkoff via Firebird-devel

On 8/10/22 10:36, Pavel Cisar wrote:

Hi,

Dne 09. 08. 22 v 17:02 Alex Peshkoff via Firebird-devel napsal(a):

*Pavel & Pavel!*

I understand you have some problems with testing system due to 
unablity to create self-security database remotely. But I do not 
understand how could as solution be suggested not to check 
credetioals at all, i.e. let everyone create databases. That's like 
let everyone atach to server and enter SYSDBA password when security 
database failed to proper initialize at install phaze for some 
reason. We used to fight for FB security for many years (almost 
twenty) and it's very strange for me to here such suggestions. We 
added special privilege for create database in order to avoid 
creation of databases by regular users. And after it suggestion to 
let do it everyone - at least for some databases...


I did not suggested to do not authenticate user! My question was why 
user has to be authenticated AGAINST YET TO BE CREATED database. It 
simply doesn't make sense at all for me. I would expect that for 
create database, the user would be authenticated in the same way as 
for attachment to service manager. 


You wrongly understand how does security in service manager work. Yes, 
you *may* do not mention database you plan to work with as long as that 
database is served by default security database. But try yourself to 
attach to service manager not specifying what database you plan to work 
with and after it backup some self-security database.


The reason is that user does not need to have any prior valid 
attachment to call create database, so credentials passed for create 
database should be used to verify that such database could be created 
for that user, but not the database specification itself! It should be 
used for connection to created database, but not for creation. It's 
IMHO illogical that setting for not yet created database are used to 
do that (which fails when created db is self-security) instead default 
security database. 


Once again - credentials are used not to check an ability to attach or 
create database (or use services manager). When server verifies them it 
has no idea about particular operation, just an ability to attach to 
server is checked.


The creation of self-security db via local (i.e. bypass of 
authentication check) is IMHO a hackish workaround that beats the 
purpose of security, because self-security databases could NOT be ever 
created in insecure way.


You mix local (xnet) protocol and embedded connection. An ability to 
establish embedded connecton means that one is able to start processes 
on the host (like hexeditor for example) and has R/W access to database 
file (or a directory where it's going to be created). Also one can just 
copy earlier created database under the name mentioned in databases.conf 
- and that is perfectly good way to go.


I.e. when embedded connection is used user does not create database on 
firebird server, he just creates a file on the host, running firebird 
server. FB tools (like isql) may be used for it or may be not. Therefore 
it's impossible to talk about beatibg FB security - it just does not 
work here because it can not work! What about 'hackish workaround' I do 
not agree - embedded access to databases is our documented feature and 
recommended in some cases and actively used by some users for a long time.




I can think about letting user, authenticated in default security 
database with appr.privileges, create self-security databases 
remotely. But definitely not what was suggested.


Yes, that was suggested, just probably wrongly worded. 


OK, in that case looks like we have some common understanding. Just 
please forget that ...


I though that when referencing that right to create database should be 
checked in the same way as attachment to service manager (which does 
not use some database reference passed by user to decide which 
security db to use) instead database that does not exists yet is quite 
clear.




attachment to services manager let's one bypass per-database security 
checks :-)


But that change does not appear to be trivial - it should be done not to 
break security architecture.
Just for example - what to do when database is created with overwrite 
option? Where to check credentials on server attach? Remember - at that 
step we have no idea why does user wants to attach to server, moreover - 
is overwrite option used.





Firebird-Devel mailing list, web interface at 
https://lists.sourceforge.net/lists/listinfo/firebird-devel


Re: [Firebird-devel] Ability to use non-local protocol to create DB which alias is declared as self-security

2022-08-10 Thread Dimitry Sibiryakov

Pavel Cisar wrote 10.08.2022 9:36:
I though that when referencing that right to create database should be checked 
in the same way as attachment to service manager (which does not use some 
database reference passed by user to decide which security db to use)


  I would like to repeat: service attachment passes the name of security 
database to be used using isc_spb_expected_db item.


--
  WBR, SD.


Firebird-Devel mailing list, web interface at 
https://lists.sourceforge.net/lists/listinfo/firebird-devel


Re: [Firebird-devel] Ability to use non-local protocol to create DB which alias is declared as self-security

2022-08-10 Thread Pavel Cisar

Hi,

Dne 09. 08. 22 v 17:02 Alex Peshkoff via Firebird-devel napsal(a):

*Pavel & Pavel!*

I understand you have some problems with testing system due to unablity 
to create self-security database remotely. But I do not understand how 
could as solution be suggested not to check credetioals at all, i.e. let 
everyone create databases. That's like let everyone atach to server and 
enter SYSDBA password when security database failed to proper initialize 
at install phaze for some reason. We used to fight for FB security for 
many years (almost twenty) and it's very strange for me to here such 
suggestions. We added special privilege for create database in order to 
avoid creation of databases by regular users. And after it suggestion to 
let do it everyone - at least for some databases...


I did not suggested to do not authenticate user! My question was why 
user has to be authenticated AGAINST YET TO BE CREATED database. It 
simply doesn't make sense at all for me. I would expect that for create 
database, the user would be authenticated in the same way as for 
attachment to service manager. The reason is that user does not need to 
have any prior valid attachment to call create database, so credentials 
passed for create database should be used to verify that such database 
could be created for that user, but not the database specification 
itself! It should be used for connection to created database, but not 
for creation. It's IMHO illogical that setting for not yet created 
database are used to do that (which fails when created db is 
self-security) instead default security database. The creation of 
self-security db via local (i.e. bypass of authentication check) is IMHO 
a hackish workaround that beats the purpose of security, because 
self-security databases could NOT be ever created in insecure way.


I can think about letting user, authenticated in default security 
database with appr.privileges, create self-security databases remotely. 
But definitely not what was suggested.


Yes, that was suggested, just probably wrongly worded. I though that 
when referencing that right to create database should be checked in the 
same way as attachment to service manager (which does not use some 
database reference passed by user to decide which security db to use) 
instead database that does not exists yet is quite clear.


best regards
Pavel


Firebird-Devel mailing list, web interface at 
https://lists.sourceforge.net/lists/listinfo/firebird-devel