General sandbox specs?

[Lars Hallberg]

Thomas Leonard wrote:

>>Sorry, I was unclear here. I was so intriged by the zero install 
>>consept. But this realy aply to a 'mother' system runing zero install, 
>>not att all to the sandbox itself.
>>    
>>
>
>Probably. The ultimate plan doesn't involve explicit sandboxes at all, but
>runs everything in a sandbox environment of some kind.
>  
>
If You want to run software like another filebrowser, a image indexing, 
searching and dup recognising program, some free text indexing and 
search utility.... that can't realy bee sandboxed?

even if You have a good environment that fix everything, that have to be 
installd separatly, it cant use the zero install if everything by zero 
install is run in an sandbox environment?

>>If I undurstand zero install right, if somthing alreddy is in the cach, 
>>it is just run/loaded without any check.
>>So once aproved, its avalible to everyone!
>>    
>>
>
>It's run without any check whether it's in the cache or not. Checks are
>done by the application that provides the interface to run it. Having
>something in the cache makes no difference to the interface at all, except
>for speed (it's faster if already cached). But users don't see things as
>"cached" or "uncached"; everything appears available at all times (like
>with web pages).
>  
>

*Think* I understand this :-)

It's an ordenary filesystem call, that is performed strait ahed if the 
file is cached. Else it's fetched first. It can originate from an fopen, 
exec, cli... or about anything.

In the case when the file *is* cached, one don't want any extra overhead 
- becose that would affect overall system performanc.

But if it's not, the download is so much overhead so a litle more would 
not matter. Given the number of possably interfaces, this is a strategic 
point to check if the file is trusted to install. But then the check is 
only performed if the file is not cached. Thats why i don't want to cach 
untrusted stuff.... but I might have got it all wrong :-)

But doing the check att that point have it's own problems. Ther's realy 
no good way of knowing how to ask the user for permision - so I guess it 
can only fail if the file is not trusted :-(

But if thes errors are logged, some program could monitor the log and 
ask for permisions for stuff that fail, saving thes permision somewher 
wher they ar seen. Some 'zero install' aware filebrowser could of corce 
chec if file are trusted beforehand and ask for permisions, and save 
them *before* the call to the filesystem.

But my wish is that 'untrusted' file should not be accesable - even thru 
a non 'zero install' avare interface. And then caching of untrusted 
files do matter, unless You want to add owerhead to the cached case 
(witch probably dont need to be big... the trust is per uri? Then the 
directory can be flagged untrusted when downloded with help of 
filesystem atributes or somthing other 'cheep'.

BTW, populating /usr/bin/ etc with symlinks to the zero install cach 
would be a way to make a system feel 'compleet' from the cli without 
installing anything? Then it is cached as used... soo cool :-)

/LaH