Re: [sqlite] O_NOFOLLOW issue with /dev/null on Solaris
Thanks for the fix, I just verified that our issue is gone. We will keep the fact that this should not happen in the first place in mind. Jakub On 2/13/20 2:50 PM, Richard Hipp wrote: On 2/13/20, jakub.ku...@oracle.com wrote: Recently, O_NOFOLLOW was added to several calls into robust_open(). In that function, if the fd returned by open() is too low (in the stdio range 0-2), then it closes it, and opens /dev/null to pad out the fd's until we reach at least fd#3. Background information: That mechanism was added as a defense again application bugs causing database corruption. See paragraph 1.1 of the "How To Corrupt an SQLite Database" document: https://urldefense.com/v3/__https://www.sqlite.org/howtocorrupt.html__;!!GqivPVa7Brio!NUDhY2pzO4PpZT0RKPQfk3_pDYeaTXiQAcUSy2MJ0MQB0f52qjDKETsBfy1QTe-Vkw$ The fact that you are hitting this problem suggests that there is something wrong with your application. Thanks for the suggested improvements to SQLite. A patch for this will appear in the next release. Or you can use the latest trunk check-in. https://urldefense.com/v3/__https://www.sqlite.org/src/timeline?c=0c683c43a62fe25c__;!!GqivPVa7Brio!NUDhY2pzO4PpZT0RKPQfk3_pDYeaTXiQAcUSy2MJ0MQB0f52qjDKETsBfy0QQEetPw$ ___ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] O_NOFOLLOW issue with /dev/null on Solaris
On 2/13/20, jakub.ku...@oracle.com wrote: > > Recently, O_NOFOLLOW was added to several calls into robust_open(). In > that function, if the fd returned by open() is too low (in the stdio > range 0-2), then it closes it, and opens /dev/null to pad out the fd's > until we reach at least fd#3. Background information: That mechanism was added as a defense again application bugs causing database corruption. See paragraph 1.1 of the "How To Corrupt an SQLite Database" document: https://www.sqlite.org/howtocorrupt.html The fact that you are hitting this problem suggests that there is something wrong with your application. Thanks for the suggested improvements to SQLite. A patch for this will appear in the next release. Or you can use the latest trunk check-in. https://www.sqlite.org/src/timeline?c=0c683c43a62fe25c -- D. Richard Hipp d...@sqlite.org ___ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
[sqlite] O_NOFOLLOW issue with /dev/null on Solaris
After sqlite 3.29 -> 3.31 upgrade, we started seeing issues related to
differences in /dev/null in Solaris.
Recently, O_NOFOLLOW was added to several calls into robust_open(). In
that function, if the fd returned by open() is too low (in the stdio
range 0-2), then it closes it, and opens /dev/null to pad out the fd's
until we reach at least fd#3.
However, it uses the same flags to open /dev/null as were passed in for
the database open(), resulting in O_NOFOLLOW being passed to
open("/dev/null"). The issue we are seeing is that /dev/null is a
symlink on Solaris, and hence this returns ELOOP, and robust_open()
returns an error.
$> ls -l /dev/null
lrwxrwxrwx 1 root root 27 Feb 12 18:05 /dev/null ->
../devices/pseudo/mm@0:null
I propose to patch this one of two ways:
a) replace the flags with known hard-coded values (as there is no
need to use caller-supplied flags to open /dev/null):
-if( osOpen("/dev/null", f, m)<0 ) break;
+if( osOpen("/dev/null", O_RDONLY, m)<0 ) break;
b) mask out the O_NOFOLLOW, but allow all others to come through.
-if( osOpen("/dev/null", f, m)<0 ) break;
+if( osOpen("/dev/null", f & ~O_NOFOLLOW, m)<0 ) break;
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
