RE: [sqlite] Temp dir
>SQLite opens the directory so that it can fsync() it. It >wants to fsync() the directory after creating the journal file >to make sure that the inode for the journal file gets created >and updated properly. > >Some unix filesystems guarantee that inodes always get updated >correctly. Others do not. If the inodes are not updated >correctly and you take a power failure, the journal file name >might not appear in the /tmp folder, and unfinished changes >might therefore not get rolled back. Perhaps this could be a behavior that is configurable based on the filesystem? I don't know if if would be done at compile time, or if it's more of a runtime parameter issue. I don't think it would matter either way when it's configured. Respectfully, Christopher
RE: [sqlite] Temp dir
>As I'm not familiar with >daemon, I can't comment further. What is this daemon? > I'm not usre about the name of it, but you can configure it with the Madriva Linux Control Center. Respectfully, Christopher
RE: [sqlite] Temp dir
chtaylo3 uttered: Christian, Or you could just fix the permissions on your temp directories. If the files in */tmp are sensitive, they should be protected. The file name themselves should not be sensitive. I'm not aware of many installations using the permissions you use for temp directories. Yes that does seem like the logical way of going about this. Unfortunately, Mandriva 2006 does have the permissions setup this way and they even have a daemon that goes around checking the file permission on certain files and dirs and changes them back to what it thinks it should be. Urgh! My only recommendation in this case is to NOT use Mandriva. Asking around has indicated that the daemon can be configured to use more sane permissions or ignore certain directories. As I'm not familiar with daemon, I can't comment further. What is this daemon? pyslite allows me to use "pragma temp_store_directory = 'directory-name';" as a parameter to the cur.execute so I'll talk with the people in trac and see if this will work for them. Any thoughts on this? There is no reason why trac can't create it's own temporary directory in /usr/tmp and use that. When writing scripts that require temporary files, I generally do this so that cleanup from the script is simply to remove the directory. Respectfully, Christopher -- /"\ \ /ASCII RIBBON CAMPAIGN - AGAINST HTML MAIL X - AGAINST MS ATTACHMENTS / \
Re: [sqlite] Temp dir
chtaylo3 <[EMAIL PROTECTED]> wrote: > Jay, > > >It's important that the journal file be preserved between reboots. > >If the power fails you can then recover the database using the journal. > >If your code has to go on one of the linuxes(linuxii??) > >that follow posix/LSG standards you'll want to know how to make > >it work correctly on those machines. > > That makes perfect sence. So you'd want sqlite to use /var/tmp. > > The question still remains why one needs to read the contents of the dir. > Why > not just try to create (as opposed to open) a file using fopen and then if it > fails because the file already exists, just increment the filename until you > get a filename that's not in use? > SQLite opens the directory so that it can fsync() it. It wants to fsync() the directory after creating the journal file to make sure that the inode for the journal file gets created and updated properly. Some unix filesystems guarantee that inodes always get updated correctly. Others do not. If the inodes are not updated correctly and you take a power failure, the journal file name might not appear in the /tmp folder, and unfinished changes might therefore not get rolled back. -- D. Richard Hipp <[EMAIL PROTECTED]>
Re: [sqlite] Temp dir
On 7/24/06, chtaylo3 <[EMAIL PROTECTED]> wrote: Jay, >It's important that the journal file be preserved between reboots. >If the power fails you can then recover the database using the journal. >If your code has to go on one of the linuxes(linuxii??) >that follow posix/LSG standards you'll want to know how to make >it work correctly on those machines. That makes perfect sence. So you'd want sqlite to use /var/tmp. The question still remains why one needs to read the contents of the dir. Why not just try to create (as opposed to open) a file using fopen and then if it fails because the file already exists, just increment the filename until you get a filename that's not in use? I may be wrong but I thought internally fopen calls read the directory to find the entry for the file it wanted to open. I remember several times having to set permissions more lax than I thought necessary to get things to work. I never checked why since I was rushed for time.
RE: [sqlite] Temp dir
Jay, >It's important that the journal file be preserved between reboots. >If the power fails you can then recover the database using the journal. >If your code has to go on one of the linuxes(linuxii??) >that follow posix/LSG standards you'll want to know how to make >it work correctly on those machines. That makes perfect sence. So you'd want sqlite to use /var/tmp. The question still remains why one needs to read the contents of the dir. Why not just try to create (as opposed to open) a file using fopen and then if it fails because the file already exists, just increment the filename until you get a filename that's not in use? Respectfully, Christopher
RE: [sqlite] Temp dir
Christian, > >Or you could just fix the permissions on your temp directories. If the >files in */tmp are sensitive, they should be protected. The file name >themselves should not be sensitive. > >I'm not aware of many installations using the permissions you use for temp >directories. Yes that does seem like the logical way of going about this. Unfortunately, Mandriva 2006 does have the permissions setup this way and they even have a daemon that goes around checking the file permission on certain files and dirs and changes them back to what it thinks it should be. pyslite allows me to use "pragma temp_store_directory = 'directory-name';" as a parameter to the cur.execute so I'll talk with the people in trac and see if this will work for them. Any thoughts on this? Respectfully, Christopher
Re: [sqlite] Temp dir
On 7/24/06, chtaylo3 <[EMAIL PROTECTED]> wrote: >/tmp : Temporary files >/var/tmp : Temporary files preserved between system reboots What does this have to do with having the tmp dir's as global read? It's important that the journal file be preserved between reboots. If the power fails you can then recover the database using the journal. If your code has to go on one of the linuxes(linuxii??) that follow posix/LSG standards you'll want to know how to make it work correctly on those machines. Mandriva 2006 has a daemon (not sure what the name is) that checks the permissions of certain folders, in this case /var/tmp, usr/tmp, and /tmp and sets them to aforementioned settings if anything changes, so it's not like I'm out in left field with the permissions set up the way they are. I don't know about Mandriva's tradeoffs of following standards vs preventing data theft. -- SqliteImporter and SqliteReplicator: Command line utilities for Sqlite http://www.reddawn.net/~jsprenkl/Sqlite Cthulhu Bucks! http://www.cthulhubucks.com
RE: [sqlite] Temp dir
>/tmp : Temporary files >/var/tmp : Temporary files preserved between system reboots What does this have to do with having the tmp dir's as global read? Mandriva 2006 has a daemon (not sure what the name is) that checks the permissions of certain folders, in this case /var/tmp, usr/tmp, and /tmp and sets them to aforementioned settings if anything changes, so it's not like I'm out in left field with the permissions set up the way they are. -Christopher
Re: [sqlite] Temp dir
On 7/21/06, chtaylo3 <[EMAIL PROTECTED]> wrote: >Set the global variable sqlite3_temp_directory to any >directory you want and it tries that directory first. Ok, fair enough. But why do you try and open the directory? Why can you just try and create the tmp file there and deal with it if it's not allowed? I'm asking becuase I have permissions for tmp folders (/tmp, /usr/tmp, /var/tmp) set at a reasonable: drwxrwx-wt 4 root adm4096 Jul 21 15:18 tmp/ /tmp : Temporary files Purpose The /tmp directory must be made available for programs that require temporary files. Programs must not assume that any files or directories in /tmp are preserved between invocations of the program. Tip Rationale IEEE standard P1003.2 (POSIX, part 2) makes requirements that are similar to the above section. Although data stored in /tmp may be deleted in a site-specific manner, it is recommended that files and directories located in /tmp be deleted whenever the system is booted. FHS added this recommendation on the basis of historical precedent and common practice, but did not make it a requirement because system administration is not within the scope of this standard. /var/tmp : Temporary files preserved between system reboots Purpose The /var/tmp directory is made available for programs that require temporary files or directories that are preserved between system reboots. Therefore, data stored in /var/tmp is more persistent than data in /tmp. Files and directories located in /var/tmp must not be deleted when the system is booted. Although data stored in /var/tmp is typically deleted in a site-specific manner, it is recommended that deletions occur at a less frequent interval than /tmp. from this page: http://www.pathname.com/fhs/pub/fhs-2.3.html#VARSPOOLAPPLICATIONSPOOLDATA
RE: [sqlite] Temp dir
chtaylo3 uttered: Set the global variable sqlite3_temp_directory to any directory you want and it tries that directory first. Ok, fair enough. But why do you try and open the directory? Why can you just try and create the tmp file there and deal with it if it's not allowed? I'm asking becuase I have permissions for tmp folders (/tmp, /usr/tmp, /var/tmp) set at a reasonable: drwxrwx-wt 4 root adm4096 Jul 21 15:18 tmp/ and I'm running an application (trac) as a non-privlidged user.. Pretty standard so far. Said user/program therefore is not allowed to read the entire tmp dir, nor do I want it to. It is however allowed to create files and operate on them. I think that if you just tried to create the file and handle exemptions after that (no dir access, file already exists, etc) then this would work just as well, no? Of course, an obvious workaround in the mean time is for the author of trac to go ahead and set the sqlite_temp_directory per your suggestion. Or you could just fix the permissions on your temp directories. If the files in */tmp are sensitive, they should be protected. The file name themselves should not be sensitive. I'm not aware of many installations using the permissions you use for temp directories. Respectfully, Christopher Taylor -- /"\ \ /ASCII RIBBON CAMPAIGN - AGAINST HTML MAIL X - AGAINST MS ATTACHMENTS / \
RE: [sqlite] Temp dir
>Set the global variable sqlite3_temp_directory to any >directory you want and it tries that directory first. Ok, fair enough. But why do you try and open the directory? Why can you just try and create the tmp file there and deal with it if it's not allowed? I'm asking becuase I have permissions for tmp folders (/tmp, /usr/tmp, /var/tmp) set at a reasonable: drwxrwx-wt 4 root adm4096 Jul 21 15:18 tmp/ and I'm running an application (trac) as a non-privlidged user.. Pretty standard so far. Said user/program therefore is not allowed to read the entire tmp dir, nor do I want it to. It is however allowed to create files and operate on them. I think that if you just tried to create the file and handle exemptions after that (no dir access, file already exists, etc) then this would work just as well, no? Of course, an obvious workaround in the mean time is for the author of trac to go ahead and set the sqlite_temp_directory per your suggestion. Respectfully, Christopher Taylor
Re: [sqlite] Temp dir
chtaylo3 <[EMAIL PROTECTED]> wrote:
> I have a question about os_unix.c
>
> On line 854 inside function sqlite3UnixTempFileName, you declare:
> static const char *azDirs[] = {
> 0,
> "/var/tmp",
> "/usr/tmp",
> "/tmp",
> ".",
> };
>
> I'm guessing this is where sqlite attempts to create a temp copy of the
> database it's opening.
Nope. This is where it puts temporary tables you create
using CREATE TEMP TABLE.
>
> I'm having difficulties with this because I'm running apache & trac (
> http://trac.edgewall.org/ ) as a non-priviliged user (of course) and
> subsequently it does not have read access to either of these directories. Is
> there a chance it could, at runtime, eval the environment variable $TMP and
> use that as one of the options?
>
> It looks like creating the temp file fails if and only if all of the dirs
> listed in azDirs is accessible. So just adding the env var $TMP should solve
> this problem. Do you agree? if so, I'd be happy to write a patch for this.
>
Set the global variable sqlite3_temp_directory to any
directory you want and it tries that directory first.
--
D. Richard Hipp <[EMAIL PROTECTED]>
[sqlite] Temp dir
I have a question about os_unix.c
On line 854 inside function sqlite3UnixTempFileName, you declare:
static const char *azDirs[] = {
0,
"/var/tmp",
"/usr/tmp",
"/tmp",
".",
};
I'm guessing this is where sqlite attempts to create a temp copy of the
database it's opening.
I'm having difficulties with this because I'm running apache & trac (
http://trac.edgewall.org/ ) as a non-priviliged user (of course) and
subsequently it does not have read access to either of these directories. Is
there a chance it could, at runtime, eval the environment variable $TMP and
use that as one of the options?
It looks like creating the temp file fails if and only if all of the dirs
listed in azDirs is accessible. So just adding the env var $TMP should solve
this problem. Do you agree? if so, I'd be happy to write a patch for this.
Respectfully,
Christopher
