Re: [sqlite] using the SQLITE_BUSY and BEGIN IMMEDIATE

[Simon Slavin]

On 10 Jul 2012, at 7:50pm, "deltagam...@gmx.net"  wrote:

> sqlite3_busy_timeout(db, 23) e.g.

23 milliseconds is a very little time for a timeout.  Even just a hard disk 
spinning up can take 800 milliseconds.

Can I suggest, for testing purposes, that you use a timeout of perhaps 5000 
milliseconds ?  If you're still getting SQLITE_BUSY or SQLITE_LOCKED with that 
timeout, then you really do have something that need proper planning.

Simon.
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] using the SQLITE_BUSY and BEGIN IMMEDIATE

[Marcus Grimm]

Am 2012-07-10 20:50, schrieb deltagam...@gmx.net:

In  http://ideone.com/eWPWD  is my example code.

I would like to know if this would be an appropiate implemetation/use 
of

BEGIN IMMEDIATE
and sqlite3_busy_timeout.


sqlite3_busy_timeout is specified once per db connection.
Probably at the beginning after sqlite_open

However, I think you slightly missinterpret the story about
SQLITE_BUSY:
First of all: Any sql operation that works on the DB might
return with an SQLITE_BUSY - No matter if its SELECT, INSERT, BEGIN, 
COMMIT, etc.


It is in the hand of programmer to deal with that:

a) by some help from sqlite by using the busy timeout, which
   internally causes sqlite to retry a statement until the timeout.
b) by manually retrying the operation that returns
   the busy state.

Be aware that you may not only deal with SQLITE_BUSY but also
with SQLITE_LOCKED.

By surrounding you sql commands with an BEGIN IMMEDIATE you just
move the issue from the INSERT command one level up to the BEGIN
statement - the principal handling of SQLITE_BUSY remains untouched.

I think the tip to use BEGIN IMMEDIATE concerns the deadlock situation
rather than a simple busy handling: It is used to make sure that a
typical cursor operation on a table that might change data in
the DB doesn't dead lock because another process has a pending lock
acquired in parallel. But that's another story anyway...

Marcus



As I understood from the documentation and literature about 
Transaction

and locks
the sqlite3_step is the action state part so I enclosed sqlite3_step
with BEGIN IMMEDIATE and COMMIT, but then occurred errors from the
sqlite3_prepare_v2

In http://www.mail-archive.com/sqlite-users@sqlite.org/msg17107.html
is explained why the sqlite3_prepare_v2
can cause a SQLITE_BUSY


So  I enclosed now all db-concerning steps with BEGIN IMMEDIATE
and COMMIT.
With this construction appear still some database lock errors but 
lesser

then with a
sqlite3_busy_timeout(db, 23) e.g.

As I understood, the BEGIN IMMEDIATE would try to get the RESERVED 
lock

once, and if it fails it gets a SQLITE_BUSY.

The BEGIN IMMEDIATE will however try to get the RESERVED lock many 
times
, if a sqlite3_busy_timeout is defined, but all tries happen within 
the

time defined by the sqlite3_busy_timeout.
This behaviour is promoted here
http://www.mail-archive.com/sqlite-users@sqlite.org/msg10447.html


Or is it like this, that
BEGIN IMMEDIATE tries it again exactly once again after the timeout ?
In literature it is also mentioned  that the BEGIN IMMEDIATE has to 
be

resetted.
How and where do I have to do this in my example code ?


I would appreciate some suggestions

___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users


___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

[sqlite] using the SQLITE_BUSY and BEGIN IMMEDIATE

[deltagam...@gmx.net]

In  http://ideone.com/eWPWD  is my example code.

I would like to know if this would be an appropiate implemetation/use of
BEGIN IMMEDIATE
and sqlite3_busy_timeout.

As I understood from the documentation and literature about Transaction
and locks
the sqlite3_step is the action state part so I enclosed sqlite3_step
with BEGIN IMMEDIATE and COMMIT, but then occurred errors from the
sqlite3_prepare_v2

In http://www.mail-archive.com/sqlite-users@sqlite.org/msg17107.html is 
explained why the sqlite3_prepare_v2

can cause a SQLITE_BUSY


So  I enclosed now all db-concerning steps with BEGIN IMMEDIATE
and COMMIT.
With this construction appear still some database lock errors but lesser
then with a
sqlite3_busy_timeout(db, 23) e.g.

As I understood, the BEGIN IMMEDIATE would try to get the RESERVED lock
once, and if it fails it gets a SQLITE_BUSY.

The BEGIN IMMEDIATE will however try to get the RESERVED lock many times
, if a sqlite3_busy_timeout is defined, but all tries happen within the
time defined by the sqlite3_busy_timeout.
This behaviour is promoted here 
http://www.mail-archive.com/sqlite-users@sqlite.org/msg10447.html



Or is it like this, that
BEGIN IMMEDIATE tries it again exactly once again after the timeout ?
In literature it is also mentioned  that the BEGIN IMMEDIATE has to be
resetted.
How and where do I have to do this in my example code ?


I would appreciate some suggestions

___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Parsing sqlitedb file.

[Andrew Barnes]

> 
> Message: 6
> Date: Mon, 9 Jul 2012 22:17:02 -0700 (PDT)
> From: rsharnagate 
> To: sqlite-users@sqlite.org
> Subject: Re: [sqlite] Parsing sqlitedb file.
> Message-ID:
>   

Re: [sqlite] SQLite4 key encoding bug

[Richard Hipp]

On Tue, Jul 10, 2012 at 11:54 AM, Igor Tandetnik wrote:

> On 7/10/2012 11:44 AM, Richard Hipp wrote:
>
>> SQLite4 is still using "double" internally for floating point
>> computations.  (Yes, there are plans to change that but it has not
>> happened
>> yet.)  The bug above is due to rounding errors in the doubles,
>> specifically
>> rounding errors that occur when doing the key encoding.
>>
>
> Both 123.0 and 12323.0 should be exactly representable in a double, as far
> as I can tell.


They are.  The rounding error occurs in my code that converts them into the Key
Encoding .


>
> --
> Igor Tandetnik
>
> __**_
> sqlite-users mailing list
> sqlite-users@sqlite.org
> http://sqlite.org:8080/cgi-**bin/mailman/listinfo/sqlite-**users
>



-- 
D. Richard Hipp
d...@sqlite.org
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] SQLite4 key encoding bug

[Igor Tandetnik]

On 7/10/2012 11:44 AM, Richard Hipp wrote:

SQLite4 is still using "double" internally for floating point
computations.  (Yes, there are plans to change that but it has not happened
yet.)  The bug above is due to rounding errors in the doubles, specifically
rounding errors that occur when doing the key encoding.


Both 123.0 and 12323.0 should be exactly representable in a double, as 
far as I can tell.

--
Igor Tandetnik

___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] SQLite4 key encoding bug

[Richard Hipp]

On Tue, Jul 10, 2012 at 11:33 AM, Igor Tandetnik wrote:

> On 7/10/2012 11:24 AM, Ryan Johnson wrote:
>
>> On 10/07/2012 9:58 AM,
>> bardzotajneko...@interia.pl wrote:
>>
>>> SQLite version 4.0.0 2012-07-07 12:21:48
>>> Enter ".help" for instructions
>>> Enter SQL statements terminated with a ";"
>>> sqlite> create table t(a);
>>> sqlite> insert into t values(123);
>>> sqlite> insert into t values(123.0);
>>> sqlite> insert into t values(12323);
>>> sqlite> insert into t values(12323.0);
>>> sqlite> select * from t group by 1;
>>> 123.0
>>> 12323
>>> 12323.0
>>> sqlite>
>>>
>> This is correct: 123 != 123.0 != "123" because they all have different
>> types (int/float/string).
>>
>
> Could you explain why 123 and 123.0 got grouped together, but 12323 and
> 12323.0 did not? Shouldn't the same logic apply? It's this inconsistency
> that looks qutie suspicious.
>

SQLite4 is still using "double" internally for floating point
computations.  (Yes, there are plans to change that but it has not happened
yet.)  The bug above is due to rounding errors in the doubles, specifically
rounding errors that occur when doing the key encoding.


> --
> Igor Tandetnik
>
>
> __**_
> sqlite-users mailing list
> sqlite-users@sqlite.org
> http://sqlite.org:8080/cgi-**bin/mailman/listinfo/sqlite-**users
>



-- 
D. Richard Hipp
d...@sqlite.org
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] SQLite4 key encoding bug

[Igor Tandetnik]

On 7/10/2012 11:24 AM, Ryan Johnson wrote:

On 10/07/2012 9:58 AM,
bardzotajneko...@interia.pl wrote:

SQLite version 4.0.0 2012-07-07 12:21:48
Enter ".help" for instructions
Enter SQL statements terminated with a ";"
sqlite> create table t(a);
sqlite> insert into t values(123);
sqlite> insert into t values(123.0);
sqlite> insert into t values(12323);
sqlite> insert into t values(12323.0);
sqlite> select * from t group by 1;
123.0
12323
12323.0
sqlite>

This is correct: 123 != 123.0 != "123" because they all have different
types (int/float/string).


Could you explain why 123 and 123.0 got grouped together, but 12323 and 
12323.0 did not? Shouldn't the same logic apply? It's this inconsistency 
that looks qutie suspicious.

--
Igor Tandetnik

___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] SQLite4 key encoding bug

[Ryan Johnson]

On 10/07/2012 9:58 AM, bardzotajneko...@interia.pl wrote:

SQLite version 4.0.0 2012-07-07 12:21:48
Enter ".help" for instructions
Enter SQL statements terminated with a ";"
sqlite> create table t(a);
sqlite> insert into t values(123);
sqlite> insert into t values(123.0);
sqlite> insert into t values(12323);
sqlite> insert into t values(12323.0);
sqlite> select * from t group by 1;
123.0
12323
12323.0
sqlite>
This is correct: 123 != 123.0 != "123" because they all have different 
types (int/float/string). Either create the table with typed columns to 
encourage all values to have the same type [1] or cast the group by key 
to coerce all values to the same type (not sure what happens if the type 
cast fails).


[1] See the SQLite docs for rules about automatic type conversions for 
typed columns, it's not a panacea.


Ryan

___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

[sqlite] SQLite4 key encoding bug

[bardzotajnekonto]

SQLite version 4.0.0 2012-07-07 12:21:48
Enter ".help" for instructions
Enter SQL statements terminated with a ";"
sqlite> create table t(a);
sqlite> insert into t values(123);
sqlite> insert into t values(123.0);
sqlite> insert into t values(12323);
sqlite> insert into t values(12323.0);
sqlite> select * from t group by 1;
123.0
12323
12323.0
sqlite> 
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Format string vulnerability in SQLite

[Richard Hipp]

On Tue, Jul 10, 2012 at 3:22 AM, Yury Maryshev wrote:

> Dear sirs,
>
> We have detected a vulnerabilities in SQLite for OS/2. Vulnerability
> details can be found in the attachment.
> Our disclosure policy is available here:
> http://en.securitylab.ru/lab/disclosure-policy.php
>

Thanks for the report.  However, we discontinued support for OS/2 in SQLite
on 2012-06-21.  http://www.sqlite.org/src/info/ff828c67e5


>
>
> --
> Yury Maryshev
> Security Engineer
> Positive Technologies
> Tel: +007 (495) 744-0144
> ymarys...@ptsecurity.ru
> www.ptsecurity.com
> en.securitylab.ru
>
>
> ___
> sqlite-users mailing list
> sqlite-users@sqlite.org
> http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
>
>


-- 
D. Richard Hipp
d...@sqlite.org
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Parsing sqlitedb file.

[rsharnagate]

Hi Simon,

While iterating iPhone Addressbook.sqlitedb pages, I found table records in
Table Interior page, but according to sqlite file format only child page
offsets and rowids are stored in it. So how is it possible or I am
understanding it properly

On Mon, Jul 9, 2012 at 8:34 PM, Simon Slavin-3 [via SQLite] <
ml-node+s1065341n63205...@n5.nabble.com> wrote:

>
> On 9 Jul 2012, at 10:10am, rsharnagate <[hidden 
> email]>
> wrote:
>
> > While parsing iPhone Addressbook.sqlitedb file, I encountered Table
> Internal
> > page offset in Table Leaf page. How do I parse it
>
> Are you working from
>
> 
>
> ?  Can you tell us what part of that page mentions this part ?
>
> Simon.
> ___
> sqlite-users mailing list
> [hidden email] 
> http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
>
>
> --
>  If you reply to this email, your message will be added to the discussion
> below:
>
> http://sqlite.1065341.n5.nabble.com/Parsing-sqlitedb-file-tp63198p63205.html
>  To unsubscribe from Parsing sqlitedb file., click 
> here
> .
> NAML
>


--
View this message in context: 
http://sqlite.1065341.n5.nabble.com/Parsing-sqlitedb-file-tp63198p63212.html
Sent from the SQLite mailing list archive at Nabble.com.
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

[sqlite] Format string vulnerability in SQLite

[Yury Maryshev]

Dear sirs,

We have detected a vulnerabilities in SQLite for OS/2. Vulnerability details 
can be found in the attachment.
Our disclosure policy is available here: 
http://en.securitylab.ru/lab/disclosure-policy.php


--
Yury Maryshev
Security Engineer
Positive Technologies
Tel: +007 (495) 744-0144
ymarys...@ptsecurity.ru
www.ptsecurity.com
en.securitylab.ru

(PT-2012-22) Positive Technologies Security Advisory 
Format string vulnerability in SQLite

--[ Vulnerable software ]

SQLite for OS/2 (eComStation)
Version: 3.x and earlier

Application link:
http://sqlite.org/

--[ Severity level ]

Severity level: Medium 
Impact: Arbitrary Code Execution 
Access Vector:  Network exploitable


CVSS v2: 
Base Score: 6.6 
Vector: (AV:N/AC:H/Au:N/C:C/I:P/A:P)

CVE: not assign

--[ Software Description ]

SQLite is a lightweight embedded relational database.

--[ Vulnerability Description  ]
 
While opening a file via SQLite on the OS/2 operating system (eComStation), the 
path, to be converted from a relative one to an absolute one, is handled by the 
os2FullPathname function. As part of the function’s execution process, the path 
gets into the sqlite3_snprintf function as a format string, and not as an 
argument for a format string. This allows attackers to use escape sequences in 
the format string.

The vulnerability is in the file /sqlite3.c.

Vulnerable code fragment:

static int os2FullPathname(
...
  const char *zRelative,  /* Possibly relative input path */
...
  char *zFull /* Output buffer */
){
  char *zRelativeCp = convertUtf8PathToCp( zRelative );
...
  APIRET rc = DosQueryPathInfo( (PSZ)zRelativeCp, FIL_QUERYFULLNAME, 
zFullCp, CCHMAXPATH );
  free( zRelativeCp );
  zFullUTF = convertCpPathToUtf8( zFullCp );
  sqlite3_snprintf( nFull, zFull, zFullUTF );
...

Exploitation Exapmle

Opening the database named "%s%s%s%s%s%s%s" will trigger SQLite failure.

--[ Solution ]

The issue can be solved by changing one sting in the vulnerable code fragment.
Original string:
sqlite3_snprintf( nFull, zFull, zFullUTF );
Target string:
sqlite3_snprintf( nFull, zFull, "%s", zFullUTF );

--[ Credits ]

The vulnerability was discovered by Sergey Bobrov, Positive Research Center 
(Positive Technologies Company)
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Parsing sqlitedb file.

[rsharnagate]

Hi Simon,

Yes, I am working from .
This issue encountered for ABPerson table.

On Mon, Jul 9, 2012 at 8:34 PM, Simon Slavin-3 [via SQLite] <
ml-node+s1065341n63205...@n5.nabble.com> wrote:

>
> On 9 Jul 2012, at 10:10am, rsharnagate <[hidden 
> email]>
> wrote:
>
> > While parsing iPhone Addressbook.sqlitedb file, I encountered Table
> Internal
> > page offset in Table Leaf page. How do I parse it
>
> Are you working from
>
> 
>
> ?  Can you tell us what part of that page mentions this part ?
>
> Simon.
> ___
> sqlite-users mailing list
> [hidden email] 
> http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
>
>
> --
>  If you reply to this email, your message will be added to the discussion
> below:
>
> http://sqlite.1065341.n5.nabble.com/Parsing-sqlitedb-file-tp63198p63205.html
>  To unsubscribe from Parsing sqlitedb file., click 
> here
> .
> NAML
>


--
View this message in context: 
http://sqlite.1065341.n5.nabble.com/Parsing-sqlitedb-file-tp63198p63211.html
Sent from the SQLite mailing list archive at Nabble.com.
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users