[sugar] secure /tmp and /var/tmp

[Albert Cahalan]

On 11/8/07, Ivan Krstić <krstic at solarsail.hcs.harvard.edu> wrote:
> 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?

One failure is no excuse to purposely fail in every way.

Not every application even needs access to a user's files.

The datastore has changed and apparantly will change.
Perhaps it can someday be less awkward to deal with.

In any case, yes, it is extra work and ugly code.
You're affecting every porting effort; it must be easy
to make that decision when it's somebody else's
code base getting screwed with #ifdef everywhere.

> 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.

This is nothing new. It's been standard on SunOS for ages.
The /tmp directory is in RAM, and /var/tmp is on disk.
You are not so special that you need to break everything.
AFAIK, this is even a common (normal?) setup on BSD.

BTW, if you're going to keep calling it $SAR, then you'd
better make that the real name of the variable.

> > 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.

If you don't solve it, people will just turn Bitfrost off.