Obtaining 2.6.8-1.541 source code

[Gregory G Carter]

I am not sure I agree with that notion of non root security locality 
when dealing with OS source code.

For one thing, it makes no sense to have any OS code running outside of 
a primary security or root zone.  With the possible exception of 
virtualizing the kernel source/binaries under a execution context.  
(i.e. vmware, UML...etc).

I would be OK with that as long as user space edits of the kernel where 
only distributed as binaries in root space.

But, having as you suggest a user space kernel tree from which to 
maintain system intergrity, binary or otherwise in building a system I 
think is fool hardy.

You should have a source tree that is in root space that is seperate 
from user space.

The root space is a reference point for compiling system software, in a 
predictable security context.  (i.e. root.)

Developers or users should not be permitted into that space, only sysadmins.

I think this is for obvious reasons so I won't spell them out unless 
asked too.

:-)

-gc

Matthew Miller wrote:

>On Mon, Sep 13, 2004 at 10:42:29PM -0700, Nick Coghlan wrote:
>  
>
>>The 541 src RPM from fedora.redhat.com drops a vanilla tarball, and a 
>>collection of patch & config files into /usr/src/redhat/SOURCES, but 
>>doesn't seem to give any guidance on combining those into a given kernel 
>>version. I would assume it is important to at least apply the patches in 
>>the correct order (which may or may not be alphabetical order).
>>Am I missing something obvious here?
>>    
>>
>
>I dunno if it's obvious if you're not expecting it, but: source RPMs don't
>work like binary RPMs. They contain the files from which binary RPMs are
>generated, and when you "install" one, instead of putting files into the
>system's RPM database, it just dumps them into your RPM build area. And
>since you haven't configured it otherwise, it uses the systemwide default.
>
>The default, it turns out is bad (and basically there due to a long
>legacy). What you want to do is set up a buildtree in your own home
>directory -- there's excellent instructions here:
><http://www.rpm.org/hintskinks/buildtree/>. Then, install the source RPM
>*not as root*, and edit the spec file to include your local patches, and
>rebuild. Voila, a new binary RPM kernel package which you can install.
>
>
>  
>