[sugar] secure /tmp and /var/tmp

[Mitch Bradley]

Stephen John Smoogen wrote:
> On Nov 7, 2007 7:09 PM, Albert Cahalan <acahalan at gmail.com> wrote:
>   
>> On 11/7/07, Michael Stone <michael at laptop.org> wrote:
>>     
>>> On Wed, Nov 07, 2007 at 12:06:21PM -0500, Albert Cahalan wrote:
>>>       
>>>> Next, bind-mount something appropriate onto /tmp and /var/tmp.
>>>>         
>>> I talked about this with Ivan who requested, at the time, that we
>>> continue using the $SAR directories instead of the FHS ones.
>>>
>>> The basic idea was that we actually _do not_ want activities scribbling
>>> all over the filesystem. Period. Certainly we could use the standard
>>> paths, as you suggest. However, it was an intentional design decision to
>>> break compatibility with the FHS.
>>>       
>> 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.
>>
>> 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.
>>
>>     
>
> A couple of questions from someone who is trying to catchup on what he
> might be able to do
>
> 1) How much indirection can the CPU handle via various layers (say
> unionfs ontop of unionfs etc) without bogging down the system?
>   

That would be a difficult question to answer without a lot of handwaving.

That said, the bottleneck is likely to be the  compression/decompression 
in the JFFS2 driver.  To the extent that you can avoid stuff ever 
hitting the NAND FLASH, you probably win.

> 2) How much can the flash drive handle per throughput AND lifetime limits?
>   

Throughput is dominated by compression / decompression.  The latter goes 
at about 3 MB/sec; the former is probably slower.

Lifetime is not likely to be a problem.  JFFS2 is good at spreading out 
writes.

> 3) How much can the memory system handle? since... I don't think we
> want to hit swap.
>   
Especially since there is no swap.

> If all these are generally known and been discussed already.. sorry.
>
>