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 name. -- 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. _______________________________________________ Dev mailing list [email protected] https://lists.tizen.org/listinfo/dev
