Re: [sqlite] Proposition: introduce a new SQLITE_READ_TABLE Authorizer Action Code

Richard Hipp wrote: > On 5/11/17, Clemens Ladisch wrote: >> Richard Hipp wrote: >>> ** ^When a table is referenced by a [SELECT] but no column values are >>> ** extracted from that table (for example in a query like >>> ** "SELECT count(*) FROM tab") then the [SQLITE_READ]

Re: [sqlite] Proposition: introduce a new SQLITE_READ_TABLE Authorizer Action Code

> Le 11 mai 2017 à 14:29, Richard Hipp a écrit : > > On 5/11/17, Gwendal Roué wrote: > >> 1. Existing callbacks that catch SQLITE_READ expect a non-NULL column >> > > Very well. The behavior has been changed so that an SQLITE_READ with > an

Re: [sqlite] Proposition: introduce a new SQLITE_READ_TABLE Authorizer Action Code

On 5/11/17, Gwendal Roué wrote: > 1. Existing callbacks that catch SQLITE_READ expect a non-NULL column > Very well. The behavior has been changed so that an SQLITE_READ with an empty-string column name, instead of a NULL column name, is invoked when a table referenced

Re: [sqlite] Proposition: introduce a new SQLITE_READ_TABLE Authorizer Action Code

On 5/11/17, Clemens Ladisch wrote: > Richard Hipp wrote: >> ** ^When a table is referenced by a [SELECT] but no column values are >> ** extracted from that table (for example in a query like >> ** "SELECT count(*) FROM tab") then the [SQLITE_READ] authorizer callback >> ** is

Re: [sqlite] Proposition: introduce a new SQLITE_READ_TABLE Authorizer Action Code

Richard Hipp wrote: > ** ^When a table is referenced by a [SELECT] but no column values are > ** extracted from that table (for example in a query like > ** "SELECT count(*) FROM tab") then the [SQLITE_READ] authorizer callback > ** is invoked once for that table with a NULL column name. The

Re: [sqlite] Proposition: introduce a new SQLITE_READ_TABLE Authorizer Action Code

> Le 10 mai 2017 à 18:22, Richard Hipp a écrit : > > On 5/10/17, Dominique Devienne 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

Re: [sqlite] Proposition: introduce a new SQLITE_READ_TABLE Authorizer Action Code

On 5/10/17, Dominique Devienne 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

Re: [sqlite] Proposition: introduce a new SQLITE_READ_TABLE Authorizer Action Code

> Le 10 mai 2017 à 15:06, Dominique Devienne a écrit : > > On Wed, May 10, 2017 at 1:35 PM, Gwendal Roué > wrote: > >>> Le 9 mai 2017 à 15:41, Gwendal Roué a écrit : How are you going to handle TRIGGERs ? >>> >>>

Re: [sqlite] Proposition: introduce a new SQLITE_READ_TABLE Authorizer Action Code

On Wed, May 10, 2017 at 1:35 PM, Gwendal Roué wrote: > > Le 9 mai 2017 à 15:41, Gwendal Roué a écrit : > >> How are you going to handle TRIGGERs ? > > > > That's a very good question. > > Very good news: foreign keys and triggers are 100% handled

Re: [sqlite] Proposition: introduce a new SQLITE_READ_TABLE Authorizer Action Code

> Le 9 mai 2017 à 15:41, Gwendal Roué a écrit : > >>> As a reminder, I intend to use the authorisation system in order to tell if >>> a statement has an opportunity to impact on another statement, as a support >>> for a general database observation feature. >> >> How

Re: [sqlite] Proposition: introduce a new SQLITE_READ_TABLE Authorizer Action Code

On Tue, May 9, 2017 at 3:02 PM, Simon Slavin wrote: > On 9 May 2017, at 7:23am, Gwendal Roué wrote: > > As a reminder, I intend to use the authorisation system in order to tell > if a statement has an opportunity to impact on another statement, as a

Re: [sqlite] Proposition: introduce a new SQLITE_READ_TABLE Authorizer Action Code

> Le 9 mai 2017 à 15:02, Simon Slavin a écrit : > > On 9 May 2017, at 7:23am, Gwendal Roué > wrote: > >> As a reminder, I intend to use the authorisation system in order to tell if >> a statement has an

Re: [sqlite] Proposition: introduce a new SQLITE_READ_TABLE Authorizer Action Code

On 9 May 2017, at 7:23am, Gwendal Roué wrote: > As a reminder, I intend to use the authorisation system in order to tell if a > statement has an opportunity to impact on another statement, as a support for > a general database observation feature. I’ve read your

Re: [sqlite] Proposition: introduce a new SQLITE_READ_TABLE Authorizer Action Code

> Le 9 mai 2017 à 08:23, Gwendal Roué a écrit : > > As a reminder, I intend to use the authorisation system in order to tell if a > statement has an opportunity to impact on another statement, as a support for > a general database observation feature. > > Here is the

Re: [sqlite] Proposition: introduce a new SQLITE_READ_TABLE Authorizer Action Code

> Le 9 mai 2017 à 00:21, Simon Slavin a écrit : > > Hardly anyone uses the authentication system, so far fewer people know the > answers. As a reminder, I intend to use the authorisation system in order to tell if a statement has an opportunity to impact on another

Re: [sqlite] Proposition: introduce a new SQLITE_READ_TABLE Authorizer Action Code

> Le 9 mai 2017 à 00:21, Simon Slavin a écrit : > > > On 8 May 2017, at 10:11pm, petern wrote: > >> Who is the author of the Authorizer Action Code source? > > Although SQLite is in the public domain, development of it is not typical for >

Re: [sqlite] Proposition: introduce a new SQLITE_READ_TABLE Authorizer Action Code

> Le 8 mai 2017 à 23:11, petern a écrit : > > Gwendal. I understand all that. It's also good that you've confirmed how > SQLITE_READ is actually queried by the authorizer callback interface. I > was wondering about that. Reading your earlier post, one might get

Re: [sqlite] Proposition: introduce a new SQLITE_READ_TABLE Authorizer Action Code

On 8 May 2017, at 10:11pm, petern wrote: > Who is the author of the Authorizer Action Code source? Although SQLite is in the public domain, development of it is not typical for an open source project. Almost everything you download when you download SQLite was

Re: [sqlite] Proposition: introduce a new SQLITE_READ_TABLE Authorizer Action Code

Gwendal. I understand all that. It's also good that you've confirmed how SQLITE_READ is actually queried by the authorizer callback interface. I was wondering about that. Reading your earlier post, one might get the impression that the SQLITE_READ authorizer action was not queried by the

Re: [sqlite] Proposition: introduce a new SQLITE_READ_TABLE Authorizer Action Code

Hello Peter, It's the generally the responsability of the callback implementor to test or not each authorization, depending on her needs. See https://sqlite.org/c3ref/set_authorizer.html -- Allow user to run select statements, and read col1 of t1: -- SQLITE_SELECT -- SQLITE_READ t1

Re: [sqlite] Proposition: introduce a new SQLITE_READ_TABLE Authorizer Action Code

Gwendal. Your proposal last month for adding column names to the callback parameters seemed more sensible. The first question that comes to mind when new callback modes are to being proposed is what else would be missing if the same standard were applied to every possible operation? My thought.

Re: [sqlite] Proposition: introduce a new SQLITE_READ_TABLE Authorizer Action Code

> Le 6 mai 2017 à 15:12, Gwendal Roué a écrit : > > Hello, > > This email contains a patch that introduces a new authorizer action code: > SQLITE_READ_TABLE. My patch did not work when the authorizer callback would not return SQLITE_OK. Please find the fixed patch

[sqlite] Proposition: introduce a new SQLITE_READ_TABLE Authorizer Action Code

Hello, This email contains a patch that introduces a new authorizer action code: SQLITE_READ_TABLE. The goal of this new action code is to fill a hole in the current authorization API, which does not tell about all tables read by a statement. For example, the statement "SELECT COUNT(*) FROM