General sandbox specs?
spam at micropp.se
Sat Mar 13 00:00:41 EET 2004
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 :-)
More information about the xdg