[sugar] secure /tmp and /var/tmp
Ivan Krstić
krstic at solarsail.hcs.harvard.edu
Thu Nov 8 07:11:52 EST 2007
On Nov 7, 2007, at 9:09 PM, Albert Cahalan wrote:
> Using standard directories is not scribbling all over
> the filesystem!
> This anti-compatibility attitude needs to stop. It's really
> hurting OLPC, needlessly making the goals harder to
> achieve. Breaking compatibility is something to be done
> as a last resort, when no alterative will work.
For better or for worse, compatibility has been broken, and on a
level as fundamental as file access. If an application can't even
access the user's files without being aware of the datastore, what
good is it to pretend that providing small bits of backwards
compatibility will make things substantially easier?
For us, $SAR/tmp lives in RAM and is severely limited (maybe to as
little as 1MB per application). $SAR/instance is used for transient
per-instance disk-backed storage. Since it's a given that work needs
to be done to port applications to Sugar, it's a _good_ thing that a
programmer is also confronted with the decision as to which of these
two temporary directories to use. Enabling a wrapper for /tmp would
have us make that decision for them, and as fellow Python programmers
know: explicit is better than implicit, and in the face of ambiguity,
refuse the temptation to guess.
> The long-term goal should be to support solid sandboxing
> of true all-over-the-filesystem software installs. This may
> need a unionfs filesystem so that files can be put everywhere
> without the dummy files needed for file-on-file bind mounts.
> Imagine if you could install any RPM, knowing that it had
> no way to corrupt your OS.
That goal is not something I'm spending much time thinking about. The
level of protection provided by Bitfrost is not something you can do
without serious compatibility breaks with how things are done at
present.
--
Ivan Krstić <krstic at solarsail.hcs.harvard.edu> | http://radian.org
More information about the Sugar
mailing list