[Sugar-devel] [FEATURE] [DESIGN] for Journal Plugins feature

[Sascha Silbe]

On Mon, Dec 07, 2009 at 12:09:59PM +0000, Aleksey Lim wrote:



Sorry I didn't enter into the other discussions about your features yet; 
I'm having quite a hard time understanding most of what you write. Would 
be nice if you could try to be more elaborate and explain your use cases 
and goals in more detail as that is likely to increase my understanding.


> Well, I guess there are two obvious ways, coding pure activities or
> having several views(somehow) in core. I tried 1st way while 
> developing
> Library activity in 0.84 release cycle and, at the end, I realized 
> that
> I copy/pasted much code from the shell, so tried to reimplement shell.
What did you copy most of the time? UI code or backend? If the latter, 
why? I.e. in which way was the data store API insufficient for your 
activity?

> So, we can just extend shell public API but there could be another
> issue - security reasons. I heard about plans to restrict activities 
> in
> case of searching/changing/removing objects that were not created by
> this activity. Having special API(and plugins) could soften situation
> then.
No, it will just raise exactly the same concerns again that were the 
reason for including such restrictions in Bitfrost/Rainbow, leading to 
exactly the same solutions (only certain combinations of rights granted 
by default; elevated privileges by using signed builds or explicit user 
configuration).
According to [1], those restrictions where never actually implemented. 
So when they are, we can take the use case "Data store explorer" into 
account and see whether there's anything we could do differently to 
address it. No need to design a new API to work around it, especially 
given it's a deliberate design decision.

There will always be a way for the _user_ to gain full control (*) and 
thus grant any privilege to any activity, BTW:

[2]:
>     No lockdown
>         Though in their default settings, the laptop's security 
> systems may impose various prohibitions on the user's actions, there 
> must exist a way for these security systems to be disabled. When that 
> is the case, the machine will grant the user complete control.


[1] http://wiki.laptop.org/go/Bitfrost#Current_Status
[2] http://wiki.laptop.org/go/Bitfrost#Principles
(*) At least from the upstream side. Any computer can be locked down to 
prevent the user from tampering with it (which again can be broken with 
enough sophistication from the user), there's nothing we can do about 
it. Whoever disables root access etc. is likely to disable Journal 
plugins and similar elevated rights as well.

CU Sascha

-- 
http://sascha.silbe.org/
http://www.infra-silbe.de/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 489 bytes
Desc: Digital signature
Url : http://lists.sugarlabs.org/archive/sugar-devel/attachments/20091207/967c6d39/attachment.pgp