From: justinmattock@gmail.com (Justin P. mattock)
Date: Fri, 19 Feb 2010 11:32:12 -0800
Subject: [refpolicy] Changing build.conf defaults?
In-Reply-To: <1266606102.11694.196.camel@gorn.columbia.tresys.com>
References: <1266602439.32011.88.camel@moss-pluto.epoch.ncsc.mil>	
	<1266603950.11694.188.camel@gorn.columbia.tresys.com>	
	<1266575669.5199.10.camel@linux-dbym.site>	
	<1266604986.11694.193.camel@gorn.columbia.tresys.com>	
	<4B7EDE7D.8030405@gmail.com>
	<1266606102.11694.196.camel@gorn.columbia.tresys.com>
Message-ID: <4B7EE73C.5020603@gmail.com>
To: refpolicy@oss.tresys.com
List-Id: refpolicy.oss.tresys.com

On 02/19/2010 11:01 AM, Christopher J. PeBenito wrote:
> On Fri, 2010-02-19 at 10:54 -0800, Justin P. mattock wrote:
>> On 02/19/2010 10:43 AM, Christopher J. PeBenito wrote:
>>> On Fri, 2010-02-19 at 02:34 -0800, Justin P. Mattock wrote:
>>>> On Fri, 2010-02-19 at 13:25 -0500, Christopher J. PeBenito wrote:
>>>>> On Fri, 2010-02-19 at 13:00 -0500, Stephen Smalley wrote:
>>>>>> I was wondering whether it would make sense to change the refpolicy
>>>>>> build.conf defaults to more closely reflect the actual settings in use
>>>>>> in modern distributions.  In particular, I was thinking that we are long
>>>>>> past the point where it makes sense to make MONOLITHIC=n the default
>>>>>> given that:
>>>>>> - all modern distros with SELinux use modular/managed policy, and
>>>>>> - semodule, semanage, and even setsebool -P will only work if using
>>>>>> modular/managed policy these days.
>>>>>>
>>>>>> Changing the default would eliminate at least one case of common user
>>>>>> error when building from upstream refpolicy on a modern distribution.
>>>>>>
>>>>>> Any objections to changing that default upstream?
>>>>>
>>>>> I don't.  But I'll wait for a while before changing it to see if anyone
>>>>> objects.
>>>>
>>>> no objections here.
>>>> building a binary policy is easier
>>>> than monolithic(especially in a distro environment).
>>>> i.g. no need for the source to add user/login
>>>> just semanage.
>>>
>>> One thing that I had always hoped was that semanage_expand would be able
>>> to output all of the necessary files, so that a monolithic build in
>>> refpolicy would just be a superset of modular build.  In other words, a
>>> monolithic refpolicy build would build a modular policy then link and
>>> expand the modules.  Then a lot of the makefile complexity could be
>>> dropped.  However, semodule_expand doesn't output file_contexts, at a
>>> minimum.
>>>
>>
>>
>> been using monolithic for a while, and just sat down
>> and got the whole binary build up and running
>> (still a bit hazzy with the user/login).
>>
>> but in regards to what(hopefully I'm seeing this)your saying
>> is if loading a monolithic have semanage have the ability to
>> example: /usr/sbin/semanage -DB to a monolithic and/or adjust user/login.
>> just like binary without the need for the source.
>> (well need for the source to do the initial install)
>>
>> if so.. that would be nice, i.g. with the suse thing
>> they have monolithic(if above was possible)I would not have had to
>> download any source to add login/user etc... just make the changes there
>> on the spot like binary.
>
> No, I'm just speaking of the build environment, not runtime.  I should
> have responded to my previous email rather than to yours.
>


ahh..
well in any case binary over here seems
more fitting to use nowadays.
easier to get up and running(that is once you
see/figure how semanage and semodule work).

Justin P. Mattock