Re: Fedora refpolicy patches

[Mike Edenfield <kutulu@kutulu.org>]

Christopher J. PeBenito wrote:

Having built up a few patches myself, I can say that my employer is (so 
far) willing to let me work on this kind of thing in my down time.  I'd 
be happy to help out, but I'm not sure where to jump in.

> The main points which would improve upstreaming efficiency from Dan's
> set are:
> 
> 1. description / justification
> 
> What this means tends to vary depending on what access is added by a
> patch.  A patch that allows reading of usr_t files probably doesn't need
> a big description while a patch that allows reading shadow_t does.
> "myapp breaks without this rule" isn't a very good explanation,
> especially if the access is questionable.  The app may be incorrectly
> requesting extra access or it might be a bug in the app.

I guess from my perspective there are two different things that I think 
I could help with if I knew how to proceed:

* Clearing the backlog from the current patchset.  For this, would it be 
helpful to go through the patches that Dan already posted and try to 
break them out and figure out what the justification was?  It would be 
time consuming, but for example, some of the samba changes I'm pretty 
sure I know what the motivation was, since I've made similar changes.

* Keeping the backlog from building up.  For this, would it help to have 
more people (e.g. like myself) watching bugzilla for problems and 
working up patches?  My main issue doing this right now is I don't run 
FC (I run Gentoo) but I could probably set up an environment to help 
out.  I'm also particularly aware of the problem Dan mentioned: other 
distributions aren't getting the benefits of his patches, and in some 
cases, even when they are upstreamed they are stuck behind an "if 
redhat" conditional.

> 2. style
> 
> The changes need to meet the refpolicy style guidelines.  Dan is pretty
> good about this, but with the volume, things still get by.

Are these published?  I try to make my changes "look like" existing 
policy but that's just my subjective guessing.

--Mike



--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.