[
https://issues.apache.org/jira/browse/DERBY-2766?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dag H. Wanvik updated DERBY-2766:
---------------------------------
Description:
When upgrading from a pre-10.2 level database to 10.2.* (not an issue with
10.3),
a user which can not be validated (authentication is on), is allowed to
do a full (hard) upgrade and in the process also become the database owner.
No connection is returned, though.
This happens because authentication (and rejection) happens *after* the hard
upgrade,
which also promotes the bogus user to database owner (db owner concept changed
after 10.1.*).
Since the database owner can not be changed, this is irreversible. Even if no
malevolent motive is involved, a small typo can upset things pretty bad..
See attached repro script.
was:
When upgrading from a pre-10.2 level database to 10.2.* or trunk (10.3 soon to
be),
a user which can not be validated (authentication is on), is allowed up
do a full (hard) upgrade and in the process also become the database owner.
No connection is returned, though.
This happens because authentication (and rejection) happens *after* the hard
upgrade,
which also promotes the bogus user to database owner (db owner concept changed
after 10.1.*).
Since the database owner can not be changed, this is irreversible. Even if no
malevolent motive is involved, a small typo can upset things pretty bad..
See attached repro script.
> Non-authenticated user gets to upgrade from pre-10.2 version databases and
> become database owner
> -------------------------------------------------------------------------------------------------
>
> Key: DERBY-2766
> URL: https://issues.apache.org/jira/browse/DERBY-2766
> Project: Derby
> Issue Type: Bug
> Components: Security
> Affects Versions: 10.2.1.6, 10.2.2.0
> Reporter: Dag H. Wanvik
> Priority: Minor
> Attachments: reproscript.sh
>
>
> When upgrading from a pre-10.2 level database to 10.2.* (not an issue with
> 10.3),
> a user which can not be validated (authentication is on), is allowed to
> do a full (hard) upgrade and in the process also become the database owner.
> No connection is returned, though.
> This happens because authentication (and rejection) happens *after* the hard
> upgrade,
> which also promotes the bogus user to database owner (db owner concept
> changed after 10.1.*).
> Since the database owner can not be changed, this is irreversible. Even if no
> malevolent motive is involved, a small typo can upset things pretty bad..
> See attached repro script.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
