[Dev] Cynara + multi-user + HOME

Carsten Haitzler c.haitzler at samsung.com
Tue Apr 15 08:02:59 GMT 2014

On 04/15/2014 04:37 PM, Patrick Ohly wrote:
> On Mon, 2014-04-14 at 21:03 +0000, Schaufler, Casey wrote:
>>> On Mon, 2014-04-14 at 15:40 +0000, Schaufler, Casey wrote:
>>>>> I have seen that and I still don't understand it. I asked explicitly for
>>>>> instructions how SMACK is supposed to be used to protect service-level
>>>>> data (see my initial mail in this thread), and so far no-one has been
>>>>> able to answer that. If the answer is in
>>>>> https://wiki.tizen.org/wiki/Security:SmackThreeDomainModel then I fail
>>>>> to see it.
>>>> Let's see if I can address the question.
>>>> The service, which I'll call S for convenience, runs in the System domain.
>>> [...]
>>> I think I already understood that part.
>>> But my question was about normal services, running in the user domain.
>>> According to the three domain model Wiki page, "system domain is
>>> comprised of the basic system services" and "user domain is comprised of
>>> the services that interact directly with the person using the Tizen
>>> system and the data those services".
>> Most services won't be in the User domain, they will be in the
>> System domain. Things like the display service are in the User
>> domain because they pretty much have to be.
> The Wiki pays says that weston-launch "and the programs it invokes" are
> in the user domain. Does that not include the D-Bus user session, all
> daemons auto-started via that or the systemd user session, and the
> actual apps?
> A quick check (Tizen IVI image, "ps -Z") confirms that the traditional
> user session, including the launchpad_preloading_preinitializing_daemon,
> indeed uses the "User" label.
> Are you saying that this will have to change?

i would not expect weston (or x11 wm/compositor etc.) to be in a special
domain. they are regular user apps - they provide a PUBLIC service for
all apps - the ability to display and get input. i wouldnt expect either
of these to use cyanara at all as they are not trying to limit access to
the service they provide (except to only the USER ID who owns that
display server or wm instance - and standard user permissioning handles

>>> Every person gets his or her own address book, so contact-service would
>>> be one example of such a service. The data will (eventually) end up in
>>> $HOME. Is there going to be some kind of protection against accidental
>>> or malicious file access from apps also running in the user domain?
>> Well, you're making some assumptions that may or may not be
>> valid.
> I'm not talking about some abstract contacts service. I was referring to
> the actual contact-service package. But okay, let's stay closer to
> something that I know better, the Evolution Data Server. That is a
> better example, too, because it is already fully multiuser capable,
> something that is work in progress for contacts-service
> (https://review.tizen.org/gerrit/#/c/16739).
> EDS gets started via D-Bus auto-activation. The data is following XDG
> standards and thus ends up in $HOME. It runs with "User" label.
> Will that service have to be modified?
>>  The contact service, using buxton, could easily be a system
>> service running safely in the System domain. The data would never
>> go into $HOME, it would be safely stored in the buxton database.
> That's not how it works. Buxton would be a very poor choice as storage
> for contact data, for performance and data modeling reasons.
>> If there is an instance of the address book per user, in the User domain,
>> it can still use buxton. Of course, you could store the information in
>> $HOME. The question then becomes what access an App needs to
>> $HOME. Why should the App have access to $HOME? Each App will
>> have a directory for its private data. There will be pre-defined directories
>> to meet the sharing requirements, and those won't be $HOME.
> My understanding of the multi-user architecture was that user
> applications and services will use $HOME. Perhaps someone working on
> that can comment?
> I looks to me like there is work going on about separating apps from the
> three domains. Not knowing about that work is what caused this confusion
> here for the rest of us (including me) who were not involved in that
> effort. May I suggest that the Wiki page gets extended to cover also
> these additional, per-app labels, and that more communication regarding
> that effort happens here on the mailing list?

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...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: OpenPGP digital signature
URL: <http://lists.tizen.org/pipermail/dev/attachments/20140415/85374bab/attachment.asc>

More information about the Dev mailing list