> -----Original Message----- > From: Tomasz Swierczek [mailto:[email protected]] > Sent: Monday, February 24, 2014 11:31 PM > To: Schaufler, Casey; Macieira, Thiago; [email protected] > Subject: RE: [Dev] Update of security framework repositories > > > > The changes proposed are in complete conflict with the Smack three > > domain > model. The code needs to be brought into compliance with the Smack three > domain model. > > I am not objecting to the *method* of integration, I am objecting to > > the > code. There needs to be a general rework of the code to conform with the > three domain model. > > This is why we put it here to rework and continue work from place where we > left it, I think this is what we discussed with Michael and you in September. > Fact is that mobile profile is not working properly and we'd like to fix it. > Maybe merge directly to tizen branch is not the best idea, maybe a > temporary place for work - but public so that you can have a look - is a > better > idea.
I think that a public (but not tizen) branch is a good idea. > We're not opposing to 3-domain model, to be clear - the fact that the code > *allows* to break it, doesn't mean it does. Manifests also can contain labels > like "foo". If you look carefully, any configuration (mapping to smack rules) > is > kept in separate repository that was *not* updated (we've moved any real > smack configuration to smack-prifilege-config repo). No one said all > privileges > we used to have will not map to one label (not AMB, but MobileMB for > example). Especially with a PolKit/gsso/?? solution controlling access to APIs > (which doesn't seem to be there, ready, on IVI). There are a bunch of files that contain Smack rules in the libprivilege-control/permissions directory. Many of these rules provide rw access. It is OK for peer domains to have rw access, but I would like the intent documented. Why are they labeled differently if they have full access? > > Security server socket labels are labeled "*", and should probably belong to > System domain - right now this would (probably) break some code. Apart > from that, we have re-worked this module to use systemd, work faster - and > lot of the ugly code has disappeared. Yes, I saw. That is good. > Libsmack - I understand that fast loading of rules may not be needed > anymore. Systemd is indeed a good place to load rules. But why nuke > optimization? There's a famous case (urban legend?) of a school that was designed as a two story building. The budget was cut, and they scaled it down to a single story. When it opened everyone was surprised to see an elevator in the lobby. The point is that unnecessary code doesn't help and can get in the way. > I believe this is the beginning of discussion that we'd like to participate > in and > just make the code better. This is not act of trying to force our point of > view. > No one pushed code directly to the repo. > > > -- > > Thiago Macieira - thiago.macieira (AT) intel.com > > Software Architect - Intel Open Source Technology Center > > > > _______________________________________________ > > Dev mailing list > > [email protected] > > https://lists.tizen.org/listinfo/dev > _______________________________________________ > Dev mailing list > [email protected] > https://lists.tizen.org/listinfo/dev > _______________________________________________ Dev mailing list [email protected] https://lists.tizen.org/listinfo/dev
