On Wednesday 21 July 2010 16:51:30 Dalton Calford wrote:
> Hi Alex,
> >> Now, from a database developers point of view, how can we tell the
> >> difference between a local user authenticated as 'DAVE', a AD user
> >> called 'DAVE' and a corporate user called 'DAVE'? It would be nice
> >> if we insisted the plugin provide the source of the authentication in
> >> the table. Ie, if it was a local windows login, you would specify
> >> manchinename\dave vs adname\dave etc.
> > Exactly like now windows trusted auth does.
> How does windows do it? I use linux extensively and do not have a
> windows based firebird server.
Depending upon domain-based or server-based auth is used, current_user
variable has domainname\username or servername\username form.
> Lets say we have a corporate active directory domain called 'CORP'.
> So the administrator on that domain would be referred to as
> We have a machine that is a member of the domain, and it is called
> 'FBServer' so the administrator account on that machine would be
> Now, lets say that we have a user 'JOE' and he is a member of the
> domain so he is referred to as 'CORP\JOE'.
> Now in FB, do I perform grants on JOE or CORP\JOE?
This depends upon how plugin will be written, I suppose ypu must grant rights
to CORP\JOE if plugin is written correctly.
> for example would it be "grant select on table foo to joe" or would it
> be "grant select on table foo to CORP\JOE"
One detail - it must be:
grant select on table foo to "CORP\JOE"
to satisfy SQL language rules.
> Because, with windows and linux, you can have a local user called joe
> - so FBSERVER\JOE can exist and be a totally different person from
> if "grant select on table foo to joe" is acceptable, then you have not
> only granted select to CORP\JOE but to FBServer\JOE as well.
> So, depending upon how 'current_user' is reported inside of the
> database, you may have a major security hole in the system. Move the
> database to another physical machine, create an account on the new
> machine to match the name of an account on the old platform, and now
> the new account has the same rights as the original account.
Dalton, if you have file-level access to database, you can always move it to a
machine where you can access it embedded, and this is always SYSDBA. I.e.
later we talk not about legal move of database file and an accidential
security hole possible in that case, yes?
> other words, the database does not have enough information to protect
> itself. In truth, you just need access to the original server or
> domain as any combination of duplicate names between the plugin
> authentication source and the new source would cause such security
> If you insist upon the plugin providing the source of the
> authentication, then you have no such problems.
It does not save you completely. Imagine that you've moved to another domain
(remote, physically different) but with same name. And you get same problem.
Next, you do not need PAM/truste auth/any external auth to get same effect!
Just imagine that grant was given to use JOE in security database, database
file was copied to another firebird server, and there is also user JOE. Same
In general this means - if one does perform file copy of database to another
server, he must take care about revoking grants. This is definitely required
> Unfortunately, I do not have a machine to perform the testing with.
You do not need it - you will get an effect.
> If current_user reports the machine name with the user name, all is
> fine except that most domain/user name combinations can be up to 254
> characters long, far larger that what I think FB can handle.
Yes, and this is a problem for windows trusted auth today.
> FB needs to increase those limits anyways, but I hope I have been
> clear in my concerns.
In FB3 it will be possible to map OS-object (it will be possible to have
really long OS objects) to database object (something like
alter user John add osname 'John\FromVeryyyyyyyyyyyyyyyyyyyyyyyyyyLongDomain'.
I'm not sure it's realistic to increase internal username limit in FB3, but
with such feature (useful in many other aspects) this limit becomes not so