On 2012-09-17 16:23, Thomas Steinmaurer wrote:
Look here:
http://www.firebirdnews.org/?p=5027
Yep, that looks exactly like my case. Unfortunately, I'm not able to
re-create users by hand because of the scale of the problem (and because
I don't know their passwords, and resetting them means me
On 2012-09-17 16:23, Thomas Steinmaurer wrote:
Look here:
http://www.firebirdnews.org/?p=5027
Yep, that looks exactly like my case. Unfortunately, I'm not able to
re-create users by hand because of the scale of the problem (and because
I don't know their passwords, and resetting them means
Yep, that looks exactly like my case. Unfortunately, I'm not able to re-create
users by hand because of the scale of the problem (and because I don't
know their passwords, and resetting them means me looking for another job
;) ).
You can pump the data to another database shell without
Alan,
I've already tried that. I described it in my previous post. The problem
is the password ciphers seem too long compared to the RDB$PASS data
type. I could try to change the type of RDB$PASS, but I don't know if
it's safe to mess with the domains in security DB.
Tomasz
On 2012-09-18
On Tue, 18 Sep 2012 09:16:30 +0100, Tomasz Tyrakowski
t.tyrakow...@sol-system.pl wrote:
Thomas,
On 2012-09-18 08:47, Thomas Steinmaurer wrote:
Neither do I. There's only the standard pre-2.0-to-2.0 security
upgrade
script. If there is such script available and someone could post a
link
to
On 2012-09-18 08:47, Thomas Steinmaurer wrote:
Neither do I. There's only the standard pre-2.0-to-2.0 security upgrade
script. If there is such script available and someone could post a link
to it, please please do.
If you are brave, you could go into firebird-devel with that. ;-)
I'll
On 2012-09-18 09:39, Mark Rotteveel wrote:
could you spend half a minute and look into your security2.fdb to check
if your varchar(64) RDB$USERS.RDB$PASS field also contains 80-character
long ciphers?
That's kind of intriguing, isn't it?
What is your connection characterset? What happens if
On 2012-09-18 08:50, Alan McDonald wrote:
You can pump the data to another database shell without touching or knowing
the passwords
Alan
I'm not quite sure the data itself is valid (and whether pumping it to
another database will fix the problem). I suspect there might be
something wrong
On 2012-09-18 08:47, Thomas Steinmaurer wrote:
If you are brave, you could go into firebird-devel with that. ;-)
Just got an answer on firebird-devel. I'll try the solution proposed by
Dmitry Yemanov and post a summary in the afternoon.
regards
Tomasz
--
Problem solved, thanks to Thomas Steinmaurer and Dmitry Yemanov.
Here's what to do when you experience problems regarding users with
elevated privileges not being able to alter other users via SQL.
1. Disconnect all clients from Firebird.
2. Copy security2.fdb to another location.
3. Connect to
Thanks for posting the summary, Tomasz. Excellent job of sleuthing!
I'm glad you figured it out in the end.
Doug C.
Hello,
I'd be very grateful if someone could repeat the scenario described
below and confirm I'm not daydreaming (should take about 1 minute). I've
tested it on FB 2.5.0.26074 CS (Linux 32 and 64 bit).
According to
http://www.firebirdsql.org/refdocs/langrefupd25-security-sql-user-mgmt.html
Hello Tomasz,
I'd be very grateful if someone could repeat the scenario described
below and confirm I'm not daydreaming (should take about 1 minute). I've
tested it on FB 2.5.0.26074 CS (Linux 32 and 64 bit).
According to
On 2012-09-17 13:07, Thomas Steinmaurer wrote:
Perhaps it might be related to CORE-3398, but I'm not sure. Any chance
to give 2.5.1 or 2.5.2 RC1 a try?
Thomas,
Thanks a lot for the suggestion. Looks like there's something wrong with
my security2.fdb (it was upgraded from previous versions of
On 2012-09-17 13:07, Thomas Steinmaurer wrote:
Perhaps it might be related to CORE-3398, but I'm not sure. Any chance
to give 2.5.1 or 2.5.2 RC1 a try?
Thomas,
Thanks a lot for the suggestion. Looks like there's something wrong with
my security2.fdb (it was upgraded from previous versions
15 matches
Mail list logo