On 07/15/2015 01:00 PM, Dmitry Yemanov wrote: > 15.07.2015 12:41, Alex Peshkoff wrote: > >> On 07/15/2015 12:20 AM, Claudio Valderrama C. wrote: >> >>> same as the strange need of >>> using sysdba to add sysdba to complete the command: >>> >>> gsec -add sysdba -pw masterkey -user sysdba >>> >>> Alex may say that one sysdba is the embedded admin and the other is the user >>> that will be added to the security db, but for the common user this command >>> flies in the face of reason. >> Claudio, your suggestions? Always run gsec as sysdba in embedded mode? >> But what to do with sql-based user management? > Something like: > gsec -init sysdba -pw masterkey > ? > > In this case -user sysdba would be assumed under the scene. In other > words, -init would be for dealing w/o permissions (embedded database > access is expected) while -add would mimic CREATE USER in SQL. > > Just an idea. >
For particular gsec we may invite a lot of solutions. For example, adding sysdba with -add switch in embedded mode can be easily detected and -user sysdba may be assumed in that case. That's rather safe, if sysdba already exists it will not be changed by add command. I worry more about SQL-based management. Creating first user is required step not only for initializing security3.fdb, it's also required when new security database (non-default) is to be added to the server. May be play this trick if an explicit user switch is not provided (i.e. OS user name is used) in embedded attachment and an attempt is made to add SYSDBA in any case, not only in gsec? ------------------------------------------------------------------------------ Don't Limit Your Business. Reach for the Cloud. GigeNET's Cloud Solutions provide you with the tools and support that you need to offload your IT needs and focus on growing your business. Configured For All Businesses. Start Your Cloud Today. https://www.gigenetcloud.com/ Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
