selinux breaks revisor

[Douglas McClendon]

Daniel P. Berrange wrote:
> On Thu, Jan 24, 2008 at 06:59:47PM -0600, Douglas McClendon wrote:
>> Daniel P. Berrange wrote:
>>
>>> Plain QEMU is unusably slow for doing any real work - particularly compute
>>> and disk intensive stuff like builds / composes.
>> Takes 12 hours to compose my 1G LiveDVD, involving a full anaconda http 
>> install under qemu, followed by mksquashfs of the result.  Honestly I do 
>> a lot of data shuffling, and think that I could probably halve that time 
>> if I wasn't more interested in further functionality at the moment than 
>> I am in performance.
> 
> A 12 hour compose time fundmanetally limits the quality / speedy delivery
> of LiveCDs because the turn around time between compose + QA cycles is being
> bottlenecked. You can only do one compose & QA cycle per day. If a chroot
> install takes < 1 hour you can get through 5 or more compose & QA cycles
> a day.

I mean no offense, but it seems like every time I say anything on this 
list, people assume it means that I am advocating some change in the 
core infrastructure that everybody should use.  When in reality, I'm 
merely trying to open the possibility to do something that just couldn't 
be done before.

My livecd generation system is dog slow, but its something that joe-user 
could download/install, and then use to create a custom livecd for 
personal or very limited use, *WITHOUT* requiring them to su to root, 
then have selinux disabled while livecd-creator runs.

Ok, so 99% of the people on this list can go ahead and think that that 
new functionality serves no useful purpose.  I admit, I don't have a lot 
of users yet.  But hey- I like it.

Getting back to your point- what I'm saying is that I'm not saying my 
tool is the right tool for everyone's job.  If you saw my anti-selinux 
rant a while back, you may have noticed that I wasn't saying that 
selinux shouldn't exist, just that maybe it isn't the right tool for 
*every* job.

A while back on this list, I asked what parts of fedora required root 
privileges to be rebuilt.  I.e. why you couldn't just rpmbuild --rebuild 
every last thing as a build user, never subjecting the build system to 
the impact of building as root.  The answer seemed to come back that the 
only things that _really_ required root, were the creation of small 
filesystem-disk images.  My tool qfakeroot provides a solution for that, 
and given the sizes of the images involved, will add but a few minutes 
to the rpmbuild--rebuild time.

> 
>> I'll take that 12 hours over the 1hr for livecd-creator any day of the 
>> week, knowing that I'm not running about 1000 rpm post install scripts 
>> under the limited protection of a chroot with selinux disabled. 
>> Combined with the comfort of knowing that if I do a compose on a 
>> different piece of hardware, that those 1000 scripts will have no chance 
>> to sneakily incur any host build dependencies based on their access to a 
>> random /proc (as opposed to the consistency of always identical qemu /proc).
> 
> Do you inspect all these %post scripts ahead of time each time you do
> a 'yum update' for your host machine. 

No.

Every time you yum update you're
> running the same scripts in your host without even the chroot protection.
> And if you don't trust the RPMs you're using to build the LiveCD images,
> why should any user trust the resulting LiveCD you're about to distribute.

Trust is not absolute.  I may want to do all kinds of experimental 
things with a LiveCD, that I wouldn't want to put on the particular 
build system.  And please, don't be obtuse like everyone seems to be on 
this list and think that I just argued 180degrees against you.  Your 
point is fine, and one I agree with, and have considered before and 
already take well into account.  I'm _only_ suggesting that _maybe_ 
there are some people out there that can appreciate the functionality 
I'm bringing to the table, even with it's relative costs.

> 
> If you really don't trust the RPMs you're about to compose, then run the
> compose on a throw away host - just re-kickstart it after execution.
> 
>> You may call 12 hours for a compose unusably slow.  I don't.  And 
>> computers and software get improved all the time, so maybe in 3 years, 
>> that 12 hours will just become "order a pizza and wait for the results".
> 
> That's a fallacy. History shows that software increases its resource
> requirements to easily match increases in hardware speed. Compare total
> install time between RHL 5 and Fedora 8 - hardware has increased in 
> performance dramatically, but install time is still effectivelly unchanged.


Yeah yeah, go ahead and be like the rest of the people here with that 
attitude.  Just focus on countering everything I say, instead of maybe, 
just maybe admitting that the functionality I'm bringing to the table 
might actually be useful for quite a few scenarios.

"Fallacy".  I mean Puhlease...  Would it cause the world to end if some 
of the core fedora developers would try to actually be constructive? 
Was your comment there _really_ necessary?  Yeah!!! you showed me how 
utterly wrong I was.  What a 'fallacy' I uttered.  Come on.  Give me a 
break.

-dmc