On Wed, 2008-07-16 at 16:19 -0400, Mike Edenfield wrote: > 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. Yes. > * 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? You could do that, or if Dan has his patch set available from a repo or even just a ftp/web site, you could just look through that. > 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. Well we definitely want distro-specific behaviors to be controlled by build options like distro_redhat, distro_gentoo, etc. If something turns out to be general, then theres nothing wrong with pulling it out of an ifdef block. > > 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. There is an interface naming guide, but not a written up style guide for the remainder of the policy. If people are becoming interested in helping out, then I can write that up. In short, most things tend to be in alphabetical order. In the TE policy, you do the declarations, then the raw allow rules, then calls to other modules interfaces' sorted first by layer (bottom up) then by alpha order. -- Chris PeBenito Tresys Technology, LLC (410) 290-1411 x150 -- 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.
