Hello,
there is a minor difference for the trace data output for an
unauthorized vs. authorized attach database event.
Successful:
2011-10-19T14:32:05.9090 (1760:05F47F48) ATTACH_DATABASE
tourism.fdb (ATT_1772, HIC:NONE, UNICODE_FSS, TCPv4:127.0.0.1)
C:\Program Files (x86)\Ups
19.10.2011 14:59, Thomas Steinmaurer wrote:
> As you can see, the role name (NONE) is missing from the connect
> information and the user name is in lower case. Just letting you know,
> perhaps this shall be changed to be consistent.
I wonder if attempted user name and password can be added to
> 19.10.2011 14:59, Thomas Steinmaurer wrote:
>> As you can see, the role name (NONE) is missing from the connect
>> information and the user name is in lower case. Just letting you know,
>> perhaps this shall be changed to be consistent.
>
> I wonder if attempted user name and password can be
On 10/19/11 17:06, Dimitry Sibiryakov wrote:
> 19.10.2011 14:59, Thomas Steinmaurer wrote:
>> As you can see, the role name (NONE) is missing from the connect
>> information and the user name is in lower case. Just letting you know,
>> perhaps this shall be changed to be consistent.
>I wonder
On 10/19/11 16:59, Thomas Steinmaurer wrote:
> Hello,
>
> there is a minor difference for the trace data output for an
> unauthorized vs. authorized attach database event.
>
> Successful:
>
> 2011-10-19T14:32:05.9090 (1760:05F47F48) ATTACH_DATABASE
> tourism.fdb (ATT_1772, HIC:NONE,
On Wed, 19 Oct 2011 15:06:33 +0200, Dimitry Sibiryakov
wrote:
> 19.10.2011 14:59, Thomas Steinmaurer wrote:
>> As you can see, the role name (NONE) is missing from the connect
>> information and the user name is in lower case. Just letting you know,
>> perhaps this shall be changed to be consisten
Dimitry Sibiryakov skriver:
19.10.2011 14:59, Thomas Steinmaurer wrote:
As you can see, the role name (NONE) is missing from the connect
information and the user name is in lower case. Just letting you know,
perhaps this shall be changed to be consistent.
I wonder if attempted user name an
19.10.2011 15:23, Mark Rotteveel wrote:
> Storing it could be a potential security breach.
But a great advantage for DBA on support. But, as Alex already said, it is
impossible.
--
SY, SD.
--
All the data continu
On Wed, 19 Oct 2011 15:27:36 +0200, Dimitry Sibiryakov
wrote:
> 19.10.2011 15:23, Mark Rotteveel wrote:
>> Storing it could be a potential security breach.
>
>But a great advantage for DBA on support. But, as Alex already said,
it
>is impossible.
True, but if it were possible, this is so
Hello Alex,
>> there is a minor difference for the trace data output for an
>> unauthorized vs. authorized attach database event.
>>
>> Successful:
>>
>> 2011-10-19T14:32:05.9090 (1760:05F47F48) ATTACH_DATABASE
>> tourism.fdb (ATT_1772, HIC:NONE, UNICODE_FSS, TCPv4:127.0.0.1)
>>
On 10/19/11 17:31, Mark Rotteveel wrote:
> On Wed, 19 Oct 2011 15:27:36 +0200, Dimitry Sibiryakov
> wrote:
>> 19.10.2011 15:23, Mark Rotteveel wrote:
>>> Storing it could be a potential security breach.
>>But a great advantage for DBA on support. But, as Alex already said,
> it
>>is impos
19.10.2011 15:31, Mark Rotteveel wrote:
> True, but if it were possible, this is something where the balance between
> convenience and security should tip to security.
Audit log is kept on the server. If a malefactor has access to server, there
is no
point to lock the door - horse is already
> 19.10.2011 15:31, Mark Rotteveel wrote:
>> True, but if it were possible, this is something where the balance between
>> convenience and security should tip to security.
>
> Audit log is kept on the server. If a malefactor has access to server,
> there is no
> point to lock the door - horse
On Wed, 19 Oct 2011 19:41:33 +0200, Thomas Steinmaurer
wrote:
>> 19.10.2011 15:31, Mark Rotteveel wrote:
>>> True, but if it were possible, this is something where the balance
>>> between
>>> convenience and security should tip to security.
>>
>> Audit log is kept on the server. If a malefacto
14 matches
Mail list logo
