On 06/14/10 07:34 PM, Karen Tung wrote:
On 06/14/10 07:16, Dave Miner wrote:
Section 6.7.1, page 12:
How are you going to guarantee that removal of snapshots
from /tmp will
not remove snapshots from other processes - e.g. are you
using a dir for
each run (/tmp/install_snapshots.PID/), just might be worth
spelling out.
Section 7.4, the second bullet point did talk about using PID for DOC
snapshots that are stored in /tmp. Do you think that's sufficient?
I think that's fine, but I would prefer to see things put in a
sub-directory -
especially in the case of DC - to avoid lots of messy files in /tmp.
(Dave has mentioned the possible mis-use of /tmp).
Based on Dave's recommendation, I will use /var/tmp.
What you said about putting checkpoint related data for a certain
run in a directory makes sense. I don't even need to use
pid to guaranteed having a unique name. I can use the Python
feature to generate a temp name that's unique. So,
each process will have it's own directory in /var/tmp like this:
/var/tmp/<tmp_dir_name>/
I did *not* recommend /var/tmp, but /var/run. They are distinctly
different.
Dave
Hi Dave,
Thanks for the correction. In my head, I was always indeed thinking about
/var/tmp, even though your email did say /var/run, :-)
probably caused by all the discussion about when/whether the DOC snapshots
will be deleted. So, I thought we want to put things in /var/tmp so the
the files does not get removed cross reboots.
Now that I realized you really mean /var/run, I have a couple questions.
Everything in /var/run will get removed cross reboot, so, it does not really
have the benefit of preserving data cross reboot. You mentioned in
your comment that since most application that uses the engine are privileged
applications, the DOC snapshots should be stored in /var/run, is it because
DOC snapshots might contain confidential data that we don't want
regular users to see? If so, in addition to putting the data in
/var/run, I would
also need to discuss the permission I set on the directories/files to
make sure that they
are really protected.
Disclosure is one aspect, interference is another; data that's written
into /tmp or any other world-writable location is of course subject to
modification by any user, and if you're expecting to read it back (which
resume would do) then you've got a vector for malicious interference.
Another concern I have is that writing to /var/run requires
the the application to have the appropriate privilege. I understand that
our installers are privileged applications, so that's not a problem.
However,
that means, if we have any applications that are not privileged in
in the future, they can not use the engine. Is that OK?
I believe my original comment answered this:
Most, if not all, applications that use the engine will be privileged
apps and as such should not be using /tmp for storage of any data.
/var/run, please, perhaps falling back to /tmp if you find that you
don't have write access there; and use TMPDIR environment variable if
you need to provide flexibility to developers or support personnel.
Dave
_______________________________________________
caiman-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
