Hi Pascal, [Re: [yocto] [meta-selinux] refpolicy update in master-next] On 14.09.22 (Mon 16:29) Pascal Ouyang wrote:
> 于 14-9-20 上午5:17, Joe MacDonald 写道: > >[Re: [meta-selinux] refpolicy update in master-next] On 14.09.18 (Thu 15:06) > >Mark Hatle wrote: > > > >>On 9/18/14, 2:57 PM, Joe MacDonald wrote: > >>>Hey all, > >>> > >>>As we'd all discussed at different times in the past, we're well behind > >>>the curve on a refpolicy update for meta-selinux. With the 1.7 release > >>>of Yocto coming up, we thought it was important to update the policy > >>>sooner rather than later, so I'm starting that work now. > >>> > >>>It's being done in master-next and currently the only recipe that has > >>>been updated is the -mls one. Over the next few days I'll be updating > >>>the others, then working through testing and trying to make sure they're > >>>all sane. It would help me out immensely if you had time to kick the > >>>tires as well on your favourite policy variant. > >>> > >>>Depending on how long this takes, the next step is updating the > >>>userspace. Fortunately this time around, though, the current userspace > >>>is still officially up to the task of managing the current policy, so a > >>>full update isn't strictly required. It'd be a really nice thing to > >>>have done, though. :-) > >>> > >> > >>I spoke with Joe about this work this morning, and I think > >>master-next is the right place to do this. So if you have immediate > >>bug fixes, we'll try to apply them to both master and master-next. > >>And then continue to use master-next to stage the policy changes (or > >>anything else that requires a bit more 'soak' time) before merging. > >> > >>I'd like to try to get 'master' of meta-selinux fully synced and > >>working with the 'master' of Poky around the time of Poky's release > >>(within a week or so of the release at least).. then we can branch > >>and let the master continue to flow with any "new" work. (It's a > >>plan, I'm not sure if it'll happen or not.) > >> > >>If anyone has any concerns let me know.. otherwise I think this is the plan! > > > >The plan proceeds! :-) > > > >Anyway, so I've now updated all of the policies in refpolicy/ and I'm > >starting in on the testing. > > > >Pascal: Can you pay particular attention to refpolicy-minimum? The > >straight forward-port of it failed to install the unconfined module > >(obviously kind of important to r-min) due to some failure inside > >prepare_policy_store(). I started debugging it, then saw that there was > >a copy in the refpolicy-minimum recipe as well as one in > >refpolicy_common.inc. Both of them need to be cleaned up, but they both > >appeared to be doing the same thing in slightly different ways. Given > >that, I turfed the one from refpolicy-minimum and it looks like the > >unconfined.pp is installed properly using the version from > >refpolicy_common. It wasn't clear looking at either the function or the > >commit log why a duplicate version of the function was placed in > >refpolicy-minimum, so please have a look to see why it was there and if > >it's still needed. > > Hi Joe, > > The original prepare_policy_store() has a naming bug for > compressed_policy, and I have fixed it. > A "clear compressed_policy distro feature" commit is also pushed, as > I have mentioned to you. Actually, I had a look at what you pushed and it wasn't quite what we talked about, I don't think. I said I'd thought there was still value in having the uncompressed policy installed on the target, but that changing the default (and obviously correcting the bug you'd mentioned where uncompressed policies were not actually being installed regardless of the flag) was fine. Here's my thinking on this. core-image-selinux contains all the tools necessary to install, create and manage policy on a system. Therefore you don't actually have to have anything except the core-image-selinux system to do anything with it. If you need to refer back to the existing policy, though, you need to either have an editor that uncompresses on the fly (which we don't actually have on the system, though I imagine something like SLIDE or SEEdit can do that, I don't know) uncompress the policy then load it into something like semodule_unpack. That's necessary because (last I checked, at least, I can go double-check now that I'm thinking about it) semodule_unpack doesn't know how to managed bzip compressed modules. And since the compressed modules are still named '*.pp', uncompressing them is kind of a pain, requiring a bit of shell dancing either dealing with 'foo.pp.out' or moving the modules around before uncompressing them. So I do think it's worth having a switch that lets you decide whether you think it's likely you'd want to unpack and manipulate module components on the system. But I'm all for the default being "no, that's not likely". Unrelated, please don't push to master-next right now, with my current debug and update workflow if you hadn't told me you'd pushed a change to master-next that hadn't been sent through the list, there's a good chance it would've gotten lost. There is a *lot* of churn in master-next right now and, as always with these branches, nothing is expected to be fast-forward for the time-being. -J. > > Thanks. :) > > - Pascal > > > > >Thanks. > > > > > -- > - Pascal -- -Joe MacDonald. :wq
signature.asc
Description: Digital signature
-- _______________________________________________ yocto mailing list [email protected] https://lists.yoctoproject.org/listinfo/yocto
