Issue Details (XML | Word | Printable)

Key: CORE-3243
Type: Bug Bug
Status: Closed Closed
Resolution: Fixed
Priority: Major Major
Assignee: Dmitry Yemanov
Reporter: GR
Votes: 0
Watchers: 3
Operations

If you were logged in you would be able to see more operations.
Firebird Core

CURRENT_USER and MON$USER raise an error for trusted authentication and non-ASCII OS user name

Created: 18/Nov/10 12:52 AM   Updated: 16/Jul/15 05:04 PM
Component/s: Charsets/Collation, Engine
Affects Version/s: 2.1.3, 2.5.0
Fix Version/s: 3.0 Alpha 1, 2.5.3

QA Status: Cannot be tested
Test Details: Requires change in OS user name and firebird.conf .


 Description  « Hide
Using Trusted Authentication and cyrillic OS user name CURRENT_USER and MON$USER
return wrong data or transliteration errors with charsets UTF8, Unicode_FSS and Win1251.

With charset NONE both work fine. It is easy to reproduce with IBE or ISQL.

Probably, there is the same problem when using TA with any non-ASCII user names.

 All   Comments   Change History   Subversion Commits      Sort Order: Ascending order - Click to sort in descending order
Alexander Peshkov added a comment - 18/Nov/10 02:40 PM
It's big surprise that WTA works at all with russian user names - according to standard CURRENT_USER must be ASCII. I have no quick idea what can be done here before 3.0, where we will be able to map OS users to database users.

But may be the problem is not SO awful? Please, check - does it work correctly with UTF16 charset?

GR added a comment - 18/Nov/10 09:13 PM
Hi, Alex.

> according to standard CURRENT_USER must be ASCII.

Really ? IIRC, it is implementation defined.
Nevertheless, mon$user is UNICODE_FSS.

> I have no quick idea what can be done here before 3.0,
> where we will be able to map OS users to database users.

There is no way to transliterate string to connection
charset correctly ? With charset NONE it works fine.

> Please, check - does it work correctly with UTF16 charset?

How to check it ? ISQL throws exceptions
"charset UTF16/UTF-16 not defined".

Dmitry Yemanov added a comment - 19/Nov/10 06:07 AM
From the SQL specification:

"The declared type of CURRENT_USER, CURRENT_ROLE, SESSION_USER, SYSTEM_USER, CURRENT_
CATALOG, CURRENT_SCHEMA, and CURRENT_PATH is character string. Whether the
character string is fixed length or variable length, and its length if it is fixed length or maximum length if
it is variable length, are implementation-defined. The character set of the character string is SQL_IDENTIFIER."

and

"SQL_IDENTIFIER is an implementation-defined character repertoire consisting of the <SQL language
character>s and all other characters that the SQL-implementation supports for use in <regular identifier>s."

So, in our case, it corresponds to UNICODE_FSS. And we do conform, as CURRENT_USER is described as ttype_metadata, which is UNICODE_FSS.

I suppose the issue is caused by the fact that AuthSspi returns the user name in the ANSI encoding (CP1251 for Russia) and it's not transliterated into UTF-8 when passed via DPB (or later, when written into usr_user_name, I'm not sure which one is correct).

Adriano dos Santos Fernandes added a comment - 19/Nov/10 09:52 AM
There is very related ticket CORE-1604. At the time, AFAIR the problem was we didn't treat user names as unicode strings at all.

Some changes were introduced more recently related to DPB items conversions, so maybe now it's possible to fix this.

Alexander Peshkov added a comment - 19/Nov/10 05:45 PM
The main problem is how does windows context authentication API return non-ascii user name. When user name contains ascii only characters this is definitely ascii. Taking into an account that we use QueryContextAttributesA to query user name, I hardly imagine how can it be UNICODE. Converting from national character sets like win1251 requires knowledge what character set is used for this particular windows version.

May be the best way is to use QueryContextAttributesU instead and always convert resulting string to UNICODE_FSS?

Adriano dos Santos Fernandes added a comment - 19/Nov/10 05:52 PM
Both approaches seems possible as we have functions to convert from system code page.

Usage of QueryContextAttributesU seems better because it won't throw an error if a valid name in the client is not representable in the server code page.

GR added a comment - 19/Nov/10 07:15 PM
> May be the best way is to use QueryContextAttributesU instead and always convert resulting string to UNICODE_FSS?

Exactly.