[Dev] Tizen 3.0 Core privilege list
patrick.ohly at intel.com
Thu Oct 30 13:13:59 GMT 2014
On Thu, 2014-10-30 at 13:19 +0100, José Bollo wrote:
> Le jeudi 30 octobre 2014 à 13:02 +0100, Patrick Ohly a écrit :
> > On Thu, 2014-10-30 at 12:49 +0100, Patrick Ohly wrote:
> > > On Thu, 2014-10-30 at 12:37 +0100, José Bollo wrote:
> > > > Le jeudi 30 octobre 2014 à 11:05 +0100, Patrick Ohly a écrit :
> > > > > Without this special privilege, each user service would have to
> > > > > implement the Smack check itself instead of using the unified privilege
> > > > > checking code paths and instance (= Cynara), or we need to revive the
> > > > > non-upstream, and otherwise obsolete Smack label checking and rules in
> > > > > dbus-daemon.
> > > >
> > > > I'm surprised to discover that the policy of checking Smack labels is
> > > > removed. I though that it remained concurrently.
> > >
> > > Reread the older mail threads. It has come up and the consensus was that
> > > checking via Cynara supersedes the older patches. We just need to figure
> > > out all details, like what how to protect services that don't have a
> > > suitable privilege.
> > It just occurred to me that the system apps with a UI that I mentioned
> > in my other email will not run with Smack label "User" or "System", so
> > the older Smack based D-Bus access control will not work for them unless
> > we also resurrect the entire "compile Smack rules based on manifest"
> > machinery from Tizen 2.x. That is currently gone in 3.x, right?
> Yes, I think so, it is gone. But what does it change? A label is a
> label, you still can enumerate it (not practical, I know...;).
What I mean is that the entire "label foo has write or read access to
bar (for bar corresponding to a privilege)" check in the old D-Bus Smack
patches has become useless for "foo" other than "System" or "User",
because there will be no rule for that anymore even if foo is meant to
have the privilege.
Therefore a service has to ask Cynara, and for that it needs a privilege
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