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@xxxxxxxxxxxxx with
the words "unsubscribe selinux" without quotes as the message.
