[sugar] secure /tmp and /var/tmp

Ivan Krstić krstic
Thu Nov 8 11:20:21 EST 2007

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  

> 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

More information about the Sugar-devel mailing list