[sugar] secure /tmp and /var/tmp

[Ivan Krstić]

On Nov 8, 2007, at 10:42 AM, Albert Cahalan wrote:
> One failure is no excuse to purposely fail in every way.

It's not a purposeful failure. We're imposing non-obvious changes on  
semantics due to restrictions in our environment, such as a strict  
limitation on the size of /tmp.

I'd _much_ rather have my application break during porting when I try  
to write to /tmp, at which point I go and think about where it should  
be writing instead, than to have it explode in strange ways when  
further writes to /tmp start erroring out because the (small amount  
of) space has been exhausted.

If I'm in the minority with this sentiment, I am open to revising the  
policy.

> This is nothing new. It's been standard on SunOS for ages.
> The /tmp directory is in RAM, and /var/tmp is on disk.

A tiny size restriction is pretty new.

> You are not so special that you need to break everything.

I am a uniquely special snowflake of unique specialness.

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

Bitfrost is not a general Linux distribution security mechanism.  
Sugar is not a general Linux desktop environment. These things are  
designed with different goals in mind, for a different purpose, and  
behave differently than the things you're used to. You can argue that  
our designs are wrong and the behaviors broken, but even that's for  
the most part orthogonal to the argument that the designs should be  
such that everything old continues to magically work. Backwards  
compatibility, quite simply, was not an OLPC design goal, and while I  
am happy to not deviate from old behavior superfluously, I also have  
an interest in doing the right thing for the new platform, especially  
when dealing with ambiguity. At the moment, I regard the /tmp  
situation as ambiguous and misleading.

--
Ivan Krstić <krstic at solarsail.hcs.harvard.edu> | http://radian.org