[Dev] Cynara + multi-user + HOME

Schaufler, Casey casey.schaufler at intel.com
Tue Apr 15 18:03:31 GMT 2014

> -----Original Message-----
> From: Patrick Ohly [mailto:patrick.ohly at intel.com]
> Sent: Tuesday, April 15, 2014 12:37 AM
> To: Schaufler, Casey; Le Foll, Dominique
> Cc: Lukasz Wojciechowski; Carsten Haitzler (The Rasterman);
> dev at lists.tizen.org
> Subject: Re: [Dev] Cynara + multi-user + HOME
> 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?

Yes, it includes the user session dbus.
> 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.

Yes, that is correct.

> Are you saying that this will have to change?

No. The launcher and user session dbus qualify as "pretty much have to be".

> > > 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?

Is it managing "privileged" resources? If it Is it will have to
start using Cynara to determine if requests for "privileged"
resources should be served.

> >  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.

Oh well.

> > 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?

The applications will have private directories under $HOME
unless they are installed for all users.

> 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?

Yes. There is still design being done with the crosswalk installation
and application launch components that will influence what this
will really look like. I would hate to document details that turn out
to be incorrect.

> --
> Best Regards, Patrick Ohly
> The content of this message is my personal opinion only and although
> I am an employee of Intel, the statements I make here in no way
> represent Intel's position on the issue, nor am I authorized to speak
> on behalf of Intel on this matter.

More information about the Dev mailing list