Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

CURRENT_USER and MON$USER raise an error for trusted authentication and non-ASCII OS user name [CORE3243] #3613

Closed
firebird-automations opened this issue Nov 18, 2010 · 13 comments

Comments

@firebird-automations
Copy link
Collaborator

Submitted by: GR (gr)

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.

Commits: dbe76bc 5e93b6b

====== Test Details ======

Requires change in OS user name and firebird.conf .

@firebird-automations
Copy link
Collaborator Author

Commented by: @AlexPeshkoff

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?

@firebird-automations
Copy link
Collaborator Author

Commented by: GR (gr)

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".

@firebird-automations
Copy link
Collaborator Author

Commented by: @dyemanov

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).

@firebird-automations
Copy link
Collaborator Author

Commented by: @asfernandes

There is very related ticket CORE1604. 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.

@firebird-automations
Copy link
Collaborator Author

Commented by: @AlexPeshkoff

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?

@firebird-automations
Copy link
Collaborator Author

Commented by: @asfernandes

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.

@firebird-automations
Copy link
Collaborator Author

Commented by: GR (gr)

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

Exactly.

@firebird-automations
Copy link
Collaborator Author

Modified by: @dyemanov

summary: CURRENT_USER and MON$USER don't work properly => CURRENT_USER and MON$USER raise an error for trusted authentication and non-ASCII OS user name

@firebird-automations
Copy link
Collaborator Author

Modified by: @dyemanov

assignee: Dmitry Yemanov [ dimitr ]

@firebird-automations
Copy link
Collaborator Author

Modified by: @dyemanov

priority: Critical [ 2 ] => Major [ 3 ]

@firebird-automations
Copy link
Collaborator Author

Modified by: @dyemanov

status: Open [ 1 ] => Resolved [ 5 ]

resolution: Fixed [ 1 ]

Fix Version: 3.0 Alpha 1 [ 10331 ]

Fix Version: 2.5.3 [ 10461 ]

@firebird-automations
Copy link
Collaborator Author

Modified by: @pcisar

status: Resolved [ 5 ] => Closed [ 6 ]

@firebird-automations
Copy link
Collaborator Author

Modified by: @pavel-zotov

status: Closed [ 6 ] => Closed [ 6 ]

QA Status: Cannot be tested

Test Details: Requires change in OS user name and firebird.conf .

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment