[OLPC Security] [sugar] secure /tmp and /var/tmp
Ivan Krstić
krstic at solarsail.hcs.harvard.edu
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
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
More information about the Security
mailing list