All of lore.kernel.org
 help / color / mirror / Atom feed
From: "David Härdeman" <david@hardeman.nu>
To: Daniel J Walsh <dwalsh@redhat.com>
Cc: selinux@tycho.nsa.gov
Subject: Re: Fedora refpolicy patches
Date: Wed, 16 Jul 2008 19:44:10 +0200	[thread overview]
Message-ID: <20080716174410.GA9226@hardeman.nu> (raw)
In-Reply-To: <487E2C1F.4010308@redhat.com>

On Wed, Jul 16, 2008 at 01:13:03PM -0400, Daniel J Walsh wrote:
>David Härdeman wrote:
>> While working on SELinux-enabling a Debian system, I often Google for
>> avc messages that show up in dmesg and 90% of the time it seems that the
>> problem has already been solved in Fedora's version of the refpolicy but
>> not in the upstream version.
...
>> The question is how to treat the patches after that? Should I post them
>> as I go through them (a couple per day for a couple of weeks?) and hope
>> that someone at Tresys will apply them?
...
>> 
>My goal is to get more then just TreSys to check in patches.  Currently
>we have a bottleneck that is not likely to be fixed.  This is not
>anyone's fault, but we are not taking advantage of OpenSource and
>allowing many hands/eyes to do this work.  Changing a module to user
>auth_use_nsswitch when we realize it calls getpw*, should be easy to get
>merged, and should not have a gatekeeper to prevent it.  If multiple
>policy writers agree on the patch, it should just go in.  Now more
>complicated changes like removing user prefix need to go much more slowly.
>
>As far as my massive fix versus a 250 minor patches, is just a matter of
>someone coming up with a better way.  I don't want to have 250 different
>patches in the spec file.  Quilt has been suggested, but I am  not
>familiar with it and am not sure how it work, nor do I have time to
>implement it.

You obviously already have a script to split the big patch into smaller 
ones. Wouldn't it be ok to have the smaller patches in a directory in 
the CVS repo, do your work against the small patches and then cat all 
patches into a big one before you do a new release? It would avoid 
having to change the .spec file and you'd be able to drop minor patches 
as they are merged upstream easily (and quilt is quite nice btw).

>My current work habit is to take AVC messages from everywhere that I get
>them. Bugzilla, Mail List, Chat Rooms, email, Personal Testing ...  And
>modify my pool.

Is that pool maintained in a repo somewhere? If not, would it perhaps be 
an idea to maintain the pool as a branch in the tresys repo?

> When I am done I run a big diff against refpolicy and
> update the patch.  So referencing all of the bugzilla's would only get
>a snapshot of the fixes and would be very time consuming and dirty up
>the patches. 

"dirty" the patches...but I'm thinking one line comments which explain 
some of the changes. I wouldn't call that dirtying the patches. For 
example, in postgrey.te, the redhat patch gives postgrey_t the ability 
to restart apache...and I can't see why. A quick one-liner which 
explained the background would have been great :)

>Getting a quilt of different fixes for each day, I do not
>believe would be of much use either since they are random.  Me
>documenting each fix and sending it immediately upstream would not help,
>since this would overwhelm me and upstream.

No, but committing one fix at a time to a repo would help, even if the 
"fix documentation" (i.e. commit message) is just "let firefox read config 
file foo".

>We are bringing on another dedicated policy writer in September,   who
>could maybe help with verifying policy changes and getting them upstream.

I guess what I'm really wondering is if I can help you in some way? 

-- 
David Härdeman

--
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.

  reply	other threads:[~2008-07-16 17:44 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-07-16 16:56 Fedora refpolicy patches David Härdeman
2008-07-16 17:13 ` Daniel J Walsh
2008-07-16 17:44   ` David Härdeman [this message]
2008-07-16 18:19     ` Christopher J. PeBenito
2008-07-16 18:59       ` Daniel J Walsh
2008-07-16 19:29         ` David Härdeman
2008-07-16 19:40           ` Daniel J Walsh
2008-07-16 20:09             ` Brett Lentz
2008-07-18 12:32               ` Christopher J. PeBenito
2008-07-18 16:52                 ` Brett Lentz
2008-07-16 20:18             ` David Härdeman
2008-07-16 22:35               ` Eric Paris
2008-07-16 20:19       ` Mike Edenfield
2008-07-17 18:00         ` Christopher J. PeBenito

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20080716174410.GA9226@hardeman.nu \
    --to=david@hardeman.nu \
    --cc=dwalsh@redhat.com \
    --cc=selinux@tycho.nsa.gov \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.