c.haitzler at samsung.com
Thu Apr 10 09:21:44 GMT 2014
On 04/10/2014 06:05 PM, Patrick Ohly wrote:
> On Wed, 2014-04-09 at 16:34 +0000, Schaufler, Casey wrote:
>>> On Wed, 2014-04-09 at 15:13 +0200, José Bollo wrote:
>>>> On mer, 2014-04-09 at 14:35 +0200, Patrick Ohly wrote:
>>>> You are right: apps not launched, not receiving the treatment have
>>>> full accesses. But to my eyes it is not a problem because:
>>>> - Tizen enforces the use of launcher (for security) so what are the
>>>> applications that aren't launched?
>>> Which Tizen profile do you refer to here?
>>> In Tizen IVI there are several user processes which do not get spawned by
>>> the launcher and thus have access to more data than they really need.
>> Those are mostly services (weston, murphyd) and basic
>> UI applications (weekeyboard). Everything on Tizen (true
>> for Android, too BTW) has access to more data than it needs.
>> The question is whether it has access to data that matters.
>> Who cares if it can read /etc/tizen-release?
> I guess it depends on the data and the goals. I'd certainly would be
> more comfortable with a Tizen device where Weston, murphyd and
> weekeyboard can't read or (worse) write my PIM data.
weston (or the display server) can just remote control your pim app,
monitor all keyboard input for passwords and more and just control the
app to export the data one way or another. it has to be assumed that
something like a displayserver etc. is already priveleged as everything
you see and all you input goes through it.
> Whether it's worth investing extra effort is up to the people defining
> the product and its requirements.
>>>> - DAC and MAC are still here filtering real intrusions
>>> But that doesn't help when the uid and smack label are the same.
>>>>> Regarding "leaving details of multi-threading to the integrator":
>>>>> that may simplify the work for the lib developer, but it complicates
>>>>> the usage of the lib for service developers, in particular if those
>>>>> services are not yet multithreaded. Just saying.
>>>> Agreed too. But remember only if it doesn't want to block.
>>> My expectation is that services will not be allowed to block. So either they
>>> are multithreaded, asynchronous or both. Cynara as currently designed does
>>> not fit into services which are asynchronous, but not multithreaded.
>> Do we have services that are asynchronous, but not multithreaded?
>> I'm all in favor of generality, but I don't believe in solving problems
>> that we don't have.
> As Jussi said, at least in the glib-based world, asynchronous without
> multithreading is the preferred model. If you need a specific example:
> syncevo-dbus-service, implementing the PIM Manager API in IVI, is not
> There's one more related issue with having a single blocking API
> function: suppose a service did create a thread to invoke that API and
> then while the check still runs needs to shut down cleanly, or (perhaps
> more realistic) the client asking for the restricted operation quits. A
> service must be prepared for this, even if it is only in the error
> handling paths. Can the service cancel the running call into Cynara?
> If it can't then it can only kill the thread, without knowing in which
> state that thread is.
> Cynara also needs to be thread-safe itself internally, of course.
The above message is intended solely for the named addressee and may
contain trade secret, industrial technology or privileged and
confidential information otherwise protected under applicable law
including the Unfair Competition Prevention and Trade Secret Protection
Act. Any unauthorized dissemination, distribution, copying or use of the
information contained in this communication is strictly prohibited. If
you have received this communication in error, please notify the sender
by email and delete this communication immediately.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 836 bytes
Desc: OpenPGP digital signature
More information about the Dev