> Le 10 mai 2017 à 18:22, Richard Hipp <d...@sqlite.org> a écrit :
> 
> On 5/10/17, Dominique Devienne <ddevie...@gmail.com> wrote:
>> 
>> We haven't heard from Richard, but I hope we will eventually.
>> 
> 
> No new authorizer codes will be added, since that would present
> compatibility problems for legacy authorizer callbacks.  Instead, the
> fix is to invoke the authorizer callback with SQLITE_READ but with a
> NULL column name for any table that is referenced but for which no
> columns are extracted.
> 
> This change is more likely to be compatible with legacy authorizer
> callbacks.  In particular, the authorizer callback used by Fossil
> (https://www.fossil-scm.org/fossil/artifact/ee53ffbf7?ln=161-221)
> continues to work fine, and with the enhanced SQLITE_READ, no prevents
> users from creating a report using
> 
>     SELECT count(*) FROM user
> 
> That returns the number of users, for example.
> 
> The fix is implemented by https://www.sqlite.org/src/timeline?c=92ab1f72 
> <https://www.sqlite.org/src/timeline?c=92ab1f72>

Thanks a lot, Richard!

I would naively expect SQLITE_READ with a NULL column a bigger threat for 
backward compatibility than a new authorizer code, because:

1. Existing callbacks that catch SQLITE_READ expect a non-NULL column

2. Existing callbacks are more likely to implement a blacklist, and use the 
authorizer code in a switch statement that does not do anything in its default 
case. The reason for favouring blacklisting over whitelisting is that the list 
of authorizer codes is not documented as closed, and that the documentation 
shows that the list of authoriser codes has already changed in the past (the 
no-longer used SQLITE_COPY).

The example below (a callback that denies access to the `token` column of the 
`users` table) would be harmed by SQLITE_READ with a NULL column because 
strcmp() isn't supposed to accept NULL input:

int denyTokenAccess(void *pUserData, int code, const char *s1, const char *s2, 
const char *s3, const char *s4) {
        switch(code) {
        case SQLITE_READ:
                if (strcmp(s1, "users") == 0 && strcmp(s2, "token") == 0) {
                        return SQLITE_DENIED;
                } else {
                        return SQLITE_OK;
                }
        default:
                return SQLITE_OK
        }
}

What do you think?
Gwendal Roué

_______________________________________________
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Reply via email to