<https://www.sqlite.org/draft/sqlar.html>
One important security issue and several unimportant ones.
Security issue:
The built-in path functions of some operating systems interpret file paths
beginning with a path separator as relative to the root of the drive rather
than the current subdirectory. For instance
tmp/read.me <-- subdirectory called 'tmp' of default path
/tmp/read.me <-- subdirectory called 'tmp' of the default drive's root
A 'name' field in a SQLite archive file could be edited to hold such a path.
This would be a vulnerability if a utility used to 'unpack' an archive is
accidentally given too much power, as 'install' scripts often are. I would
suggest some attention be paid to this issue in the command-line tools which
understand archives, that built-in functions which store the 'name' field not
store leading path separators, and that functions which restore from the 'name'
field filter out leading path separators. This could be done with a single
'sqlar_sanitizeName()' function (you can probably think of a better name for
it) called by both packer and expander functions.
You might also want to ponder whether a 'name' starting with 'c:\' should be
allowed, and what the command-line tools should do about it if it isn't.
Other issues:
Because not all operating systems use the same character as a subdirectory
separator, you might document whether archives always use the '/' character as
a path separator. Proper programmers know what they're doing, but naive
Windows users might not.
Is there a good reason for the 'sz' column to be called 'sz' and not 'size' or
'length' ? I dislike pointless abbreviation.
If you're renaming the 'sz' field, please consider whether to rename 'name' to
'path', which is closer to the industry standard.
Does the deflated stream include a header which says "what follows is deflated
data" ? If not, what will you do when users want to use better algorithms than
'Deflate' ? You need either a column which tells the user which compression
method was used (including 'none') or a function which extracts this
information from the stored BLOB.
If you expect SQLite archive files to eventually feature other methods of
compression than 'Inflate', the documentation should make it clear whether this
would be done by changing sqlar.c or by supplying other files like sqlar.c. In
the latter case, the name and functions of sqlar.c should be changed to reflect
that they are the 'Inflate' versions.
Simon.
_______________________________________________
sqlite-users mailing list
[email protected]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
