[Dev] Cynara + multi-user + HOME

Patrick Ohly patrick.ohly at intel.com
Tue Apr 15 07:37:00 GMT 2014

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?

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

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?

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