Hi, I tested revisor and wanted to make an up to date version of Fedora 8 Live CD - but selinux put a stop to that.
If there was only one bug I would report it to bugzilla but if you look at my screenshots you will see that this is a much bigger issue and I guess that it would be better that revisor and selinux guys sit together and look why it makes so many AVC Denials.
http://www.uploadgeek.com/uploads456/0/Screenshot-setroubleshoot%20browser-r... http://www.uploadgeek.com/uploads456/0/Screenshot-setroubleshoot%20browser-r...
Cheers, Valent.
On Tue, 2008-01-22 at 13:29 +0100, Valent Turkovic wrote:
Hi, I tested revisor and wanted to make an up to date version of Fedora 8 Live CD - but selinux put a stop to that.
If there was only one bug I would report it to bugzilla but if you look at my screenshots you will see that this is a much bigger issue and I guess that it would be better that revisor and selinux guys sit together and look why it makes so many AVC Denials.
http://www.uploadgeek.com/uploads456/0/Screenshot-setroubleshoot%20browser-r... http://www.uploadgeek.com/uploads456/0/Screenshot-setroubleshoot%20browser-r...
Valent, please report to Bugzilla. Please.
Thanks,
On Jan 22, 2008 1:38 PM, Lubomir Kundrak lkundrak@redhat.com wrote:
On Tue, 2008-01-22 at 13:29 +0100, Valent Turkovic wrote:
Hi, I tested revisor and wanted to make an up to date version of Fedora 8 Live CD - but selinux put a stop to that.
If there was only one bug I would report it to bugzilla but if you look at my screenshots you will see that this is a much bigger issue and I guess that it would be better that revisor and selinux guys sit together and look why it makes so many AVC Denials.
http://www.uploadgeek.com/uploads456/0/Screenshot-setroubleshoot%20browser-r... http://www.uploadgeek.com/uploads456/0/Screenshot-setroubleshoot%20browser-r...
Valent, please report to Bugzilla. Please.
Thanks,
Lubomir Kundrak (Red Hat Security Response Team)
I entered these bugs: https://bugzilla.redhat.com/show_bug.cgi?id=429681 https://bugzilla.redhat.com/show_bug.cgi?id=429676 https://bugzilla.redhat.com/show_bug.cgi?id=429677 https://bugzilla.redhat.com/show_bug.cgi?id=429678 https://bugzilla.redhat.com/show_bug.cgi?id=429682 https://bugzilla.redhat.com/show_bug.cgi?id=429683 https://bugzilla.redhat.com/show_bug.cgi?id=429684
and now bugzilla says it is busy, looks I broke the bugzilla also :)
Do I get a cookie now? :)
Valent.
On Jan 22, 2008 2:16 PM, Valent Turkovic valent.turkovic@gmail.com wrote:
On Jan 22, 2008 1:38 PM, Lubomir Kundrak lkundrak@redhat.com wrote:
On Tue, 2008-01-22 at 13:29 +0100, Valent Turkovic wrote:
Hi, I tested revisor and wanted to make an up to date version of Fedora 8 Live CD - but selinux put a stop to that.
If there was only one bug I would report it to bugzilla but if you look at my screenshots you will see that this is a much bigger issue and I guess that it would be better that revisor and selinux guys sit together and look why it makes so many AVC Denials.
http://www.uploadgeek.com/uploads456/0/Screenshot-setroubleshoot%20browser-r... http://www.uploadgeek.com/uploads456/0/Screenshot-setroubleshoot%20browser-r...
Valent, please report to Bugzilla. Please.
Thanks,
Lubomir Kundrak (Red Hat Security Response Team)
I entered these bugs: https://bugzilla.redhat.com/show_bug.cgi?id=429681 https://bugzilla.redhat.com/show_bug.cgi?id=429676 https://bugzilla.redhat.com/show_bug.cgi?id=429677 https://bugzilla.redhat.com/show_bug.cgi?id=429678 https://bugzilla.redhat.com/show_bug.cgi?id=429682 https://bugzilla.redhat.com/show_bug.cgi?id=429683 https://bugzilla.redhat.com/show_bug.cgi?id=429684
and now bugzilla says it is busy, looks I broke the bugzilla also :)
Do I get a cookie now? :)
Valent.
and two new ones: https://bugzilla.redhat.com/show_bug.cgi?id=429685 https://bugzilla.redhat.com/show_bug.cgi?id=429686
-- http://kernelreloaded.blog385.com/ linux, blog, anime, spirituality, windsurf, wireless registered as user #367004 with the Linux Counter, http://counter.li.org. ICQ: 2125241, Skype: valent.turkovic
2008/1/22 Benjamin Kreuter ben.kreuter@gmail.com:
On Tuesday 22 January 2008 08:16:22 Valent Turkovic wrote:
Do I get a cookie now? :)
Valent.
No, sorry, no cookies today. Some of those appear to be duplicates; did you receive the same SELinux denial multiple times?
-- Benjamin Kreuter
http://www.uploadgeek.com/uploads456/0/Screenshot-setroubleshoot%20browser-e...
Please look at this screenshot - these AVC Denials are only from running revisor. Bold ones are the ones I still didn't report to bugzilla.
This is ridiculous - I can sit for next hour and just copy/paste errors selinux spits out... and I have to do my work also :)
If it is crucial tell me and I'll post them tomorrow, but I still urge you to look for your self why so much errors are occurring.
Cheers, Valent.
On Tuesday 22 January 2008 08:52:57 Valent Turkovic wrote:
http://www.uploadgeek.com/uploads456/0/Screenshot-setroubleshoot%20browser- errors-galore.png
Sorry, no luck with that image -- just a broken image icon and some text from uploadgeek.
I'm not an active Revisor contributor, so I am probably not in a position to advise you on this. I was only noting that many of those bug reports appeared to be duplicates, which could be the result of some erroneous code in a loop.
-- Benjamin Kreuter
2008/1/22 Benjamin Kreuter ben.kreuter@gmail.com:
On Tuesday 22 January 2008 08:52:57 Valent Turkovic wrote:
http://www.uploadgeek.com/uploads456/0/Screenshot-setroubleshoot%20browser- errors-galore.png
Sorry, no luck with that image -- just a broken image icon and some text from uploadgeek.
I'm not an active Revisor contributor, so I am probably not in a position to advise you on this. I was only noting that many of those bug reports appeared to be duplicates, which could be the result of some erroneous code in a loop.
-- Benjamin Kreuter
-- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
This should work: http://www.uploadgeek.com/uploads456/0/Screenshot-setroubleshoot browser-errors-galore.png
On Jan 22, 2008 3:22 PM, Valent Turkovic valent.turkovic@gmail.com wrote:
2008/1/22 Benjamin Kreuter ben.kreuter@gmail.com:
On Tuesday 22 January 2008 08:52:57 Valent Turkovic wrote:
http://www.uploadgeek.com/uploads456/0/Screenshot-setroubleshoot%20browser- errors-galore.png
Sorry, no luck with that image -- just a broken image icon and some text from uploadgeek.
I'm not an active Revisor contributor, so I am probably not in a position to advise you on this. I was only noting that many of those bug reports appeared to be duplicates, which could be the result of some erroneous code in a loop.
-- Benjamin Kreuter
-- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
This should work: http://www.uploadgeek.com/uploads456/0/Screenshot-setroubleshoot browser-errors-galore.png
http://www.uploadgeek.com/uploads456/0/Screenshot-setroubleshoot%20browser-e...
third time is the charm :)
On Tuesday 22 January 2008 15:04:19 Benjamin Kreuter wrote:
On Tuesday 22 January 2008 08:52:57 Valent Turkovic wrote:
http://www.uploadgeek.com/uploads456/0/Screenshot-setroubleshoot%20browse r- errors-galore.png
Sorry, no luck with that image -- just a broken image icon and some text from uploadgeek.
I have the same problem as you if I use Konqueror as web browser. With Firefox I can see the image.
Valent Turkovic wrote:
Hi, I tested revisor and wanted to make an up to date version of Fedora 8 Live CD - but selinux put a stop to that.
If there was only one bug I would report it to bugzilla but if you look at my screenshots you will see that this is a much bigger issue and I guess that it would be better that revisor and selinux guys sit together and look why it makes so many AVC Denials.
http://www.uploadgeek.com/uploads456/0/Screenshot-setroubleshoot%20browser-r... http://www.uploadgeek.com/uploads456/0/Screenshot-setroubleshoot%20browser-r...
Screenshots are not a good way to pass information. The text of the alert in setroubleshoot can be copied to the clipboard by going to the Edit menus and selecting "Copy Alert", or you can save the text in a file by going to the File menu and selecting "Save Alert".
Either of these methods give you the full text of the alert for inclusion in a bugzilla or sharing in an email message.
On Jan 22, 2008 2:05 PM, John Dennis jdennis@redhat.com wrote:
Valent Turkovic wrote:
Hi, I tested revisor and wanted to make an up to date version of Fedora 8 Live CD - but selinux put a stop to that.
If there was only one bug I would report it to bugzilla but if you look at my screenshots you will see that this is a much bigger issue and I guess that it would be better that revisor and selinux guys sit together and look why it makes so many AVC Denials.
http://www.uploadgeek.com/uploads456/0/Screenshot-setroubleshoot%20browser-r... http://www.uploadgeek.com/uploads456/0/Screenshot-setroubleshoot%20browser-r...
Screenshots are not a good way to pass information. The text of the alert in setroubleshoot can be copied to the clipboard by going to the Edit menus and selecting "Copy Alert", or you can save the text in a file by going to the File menu and selecting "Save Alert".
Either of these methods give you the full text of the alert for inclusion in a bugzilla or sharing in an email message.
-- John Dennis jdennis@redhat.com
That is why I suggested that you (devels and mainainers of selinux and revisor) try for your self and look at the number of AVC Denials...
This looks like a pattern in fedora, looks like nobody actually does testing of these new features. If anybody tried to make a spin just to test if revisor works these errors should have sufaced... no?
Valent.
Valent Turkovic wrote:
This looks like a pattern in fedora, looks like nobody actually does testing of these new features. If anybody tried to make a spin just to test if revisor works these errors should have sufaced... no?
Such assumptions are frequently wrong. Revisor or SELinux policy packages might get updated. We could have tried different things in revisor. System SELinux labeling might be wrong because you disabled it in between and so on.
Rahul
On Jan 22, 2008 4:18 AM, Valent Turkovic valent.turkovic@gmail.com wrote:
This looks like a pattern in fedora, looks like nobody actually does testing of these new features. If anybody tried to make a spin just to test if revisor works these errors should have sufaced... no?
Just to be clear, revisor is not used internally by the fedora project to create spins. So It's not clear to me that there is an expectation that this should have priority over other things when it comes to testing.
-jef
Jeff Spaleta wrote:
On Jan 22, 2008 4:18 AM, Valent Turkovic valent.turkovic@gmail.com wrote:
This looks like a pattern in fedora, looks like nobody actually does testing of these new features. If anybody tried to make a spin just to test if revisor works these errors should have sufaced... no?
Just to be clear, revisor is not used internally by the fedora project to create spins. So It's not clear to me that there is an expectation that this should have priority over other things when it comes to testing.
-jef
We're advertising it in a very public way. More people are expecting it to work.
--CJD
On Tue, 22 Jan 2008 11:52:00 -0500 Casey Dahlin cjdahlin@ncsu.edu wrote:
We're advertising it in a very public way. More people are expecting it to work.
"We" cannot help what some other parts of the project choose to tout (:
On Jan 22, 2008 7:52 AM, Casey Dahlin cjdahlin@ncsu.edu wrote:
We're advertising it in a very public way. More people are expecting it to work.
But we aren't using it internally, we aren't dogfooding it with our spins, and I want to make sure Valent and anyone reading the thread understands that. My reading of Valent's comment informed me that he was assuming we were seeing these problems as part of spin release and implied an assumption that we were using revisor. We aren't.
Now that being said, I think any spin generation toolchain which we are offering, should be packaged in a way that informs people that selinux needs to be disabled to use correctly. And since I don't think spin creation falls into a desktop usage case of any rational merit, but falls instead into development usage, then I don't think such a tool should automatically disable selinux even temporarily.
Selinux when interacting with any chroot-like apparatus is still a problem. Perhaps its time to take stock of all the packages that rely on chroot-like behavior which are similarly affected by selinux, so that a common technical solution can be found and applied.
-jef -jef
On Jan 22, 2008 12:16 PM, Jeff Spaleta jspaleta@gmail.com wrote:
Selinux when interacting with any chroot-like apparatus is still a problem. Perhaps its time to take stock of all the packages that rely on chroot-like behavior which are similarly affected by selinux, so that a common technical solution can be found and applied.
+1
This is just a bug between SELinux and any chrooting program. It is not a reason to fetch torches and pitchforks or to complain that SELinux sucks, or any of that nonsense. Fixing the interaction between SELinux and chroot is one of those things that can only get better the more real world usage SELinux sees.
-Yaakov
On Tue, 2008-01-22 at 13:01 -0500, Yaakov Nemoy wrote:
On Jan 22, 2008 12:16 PM, Jeff Spaleta jspaleta@gmail.com wrote:
Selinux when interacting with any chroot-like apparatus is still a problem. Perhaps its time to take stock of all the packages that rely on chroot-like behavior which are similarly affected by selinux, so that a common technical solution can be found and applied.
+1
This is just a bug between SELinux and any chrooting program. It is not a reason to fetch torches and pitchforks or to complain that SELinux sucks, or any of that nonsense. Fixing the interaction between SELinux and chroot is one of those things that can only get better the more real world usage SELinux sees.
It seem to me that SELinux can provide for the same (or better) "features" of chroot without actually requiring a chrooted environment. So shouldn't we simply provide targeted policies and not use chroot for known services ?
Simo.
On Jan 22, 2008 9:04 AM, Simo Sorce ssorce@redhat.com wrote:
It seem to me that SELinux can provide for the same (or better) "features" of chroot without actually requiring a chrooted environment. So shouldn't we simply provide targeted policies and not use chroot for known services ?
If that works...then great. But I think you might want to look around first and take stock of the packages which are doing the chroots and start with something..sane.
-jef
On Jan 22, 2008 1:04 PM, Simo Sorce ssorce@redhat.com wrote:
On Tue, 2008-01-22 at 13:01 -0500, Yaakov Nemoy wrote:
On Jan 22, 2008 12:16 PM, Jeff Spaleta jspaleta@gmail.com wrote:
Selinux when interacting with any chroot-like apparatus is still a problem. Perhaps its time to take stock of all the packages that rely on chroot-like behavior which are similarly affected by selinux, so that a common technical solution can be found and applied.
+1
This is just a bug between SELinux and any chrooting program. It is not a reason to fetch torches and pitchforks or to complain that SELinux sucks, or any of that nonsense. Fixing the interaction between SELinux and chroot is one of those things that can only get better the more real world usage SELinux sees.
It seem to me that SELinux can provide for the same (or better) "features" of chroot without actually requiring a chrooted environment. So shouldn't we simply provide targeted policies and not use chroot for known services ?
Chroot provides a bunch of other 'features' (actually lack thereof) that SELinux on its own can't provide itself. SELinux can block a program from accessing certain files, or doing certain things on the machine, which is great for security. SELinux would have a harder time telling a program that a certain file doesn't exist, such as in a mock chroot. Furthermore, the chroot could be used to provide a more dynamic environment that is dissimilar to the host environment, such as using mock to build many different kinds of packages in a 'clean room'. The SELinux policy for that would have to be incredibly flexible. I don't think it's a sane idea. (I could be wrong.)
I think what you really want is SELinux to be in some ways chroot aware, so that it can handle a policy within a policy, something that would let you chroot a policy into SELinux. You'd probably want a meta-chroot-policy as well, to define who or what can or cannot use chroot. It might even make doing certain things like running mock or revisor easier to implement so that they don't neet root access, or if they do, they are better confined.
Honestly, I wish i knew more about writing policies to suggest what a better solution could be tough.
-Yaakov
On Tue, 22 Jan 2008 13:04:26 -0500 Simo Sorce ssorce@redhat.com wrote:
It seem to me that SELinux can provide for the same (or better) "features" of chroot without actually requiring a chrooted environment. So shouldn't we simply provide targeted policies and not use chroot for known services ?
That's not the point of many chroot usages. Frequently chroots are used to gain access to content from a different release or arch than what you have installed. EG we use RHEL5 to create chroots of f9 and build packages within that chroot using F9 content. Likewise we do a pure i386 package set on x86_64 to accomplish our i386 build. These types of usages cannot be easily replaced with an selinux policy.
On Tue, 2008-01-22 at 13:14 -0500, Jesse Keating wrote:
On Tue, 22 Jan 2008 13:04:26 -0500 Simo Sorce ssorce@redhat.com wrote:
It seem to me that SELinux can provide for the same (or better) "features" of chroot without actually requiring a chrooted environment. So shouldn't we simply provide targeted policies and not use chroot for known services ?
That's not the point of many chroot usages. Frequently chroots are used to gain access to content from a different release or arch than what you have installed. EG we use RHEL5 to create chroots of f9 and build packages within that chroot using F9 content. Likewise we do a pure i386 package set on x86_64 to accomplish our i386 build. These types of usages cannot be easily replaced with an selinux policy.
I am sorry, I was thinking only about the security usage of chroots. I have been using chroots for "mock like" usage myself to release samba packages for older Debian releases for many years, should have just been thinking harder :-)
What Yakoov wrote in the other emails makes a lot of sense indeed.
Simo.
Simo Sorce wrote:
On Tue, 2008-01-22 at 13:01 -0500, Yaakov Nemoy wrote:
On Jan 22, 2008 12:16 PM, Jeff Spaleta jspaleta@gmail.com wrote:
Selinux when interacting with any chroot-like apparatus is still a problem. Perhaps its time to take stock of all the packages that rely on chroot-like behavior which are similarly affected by selinux, so that a common technical solution can be found and applied.
+1
This is just a bug between SELinux and any chrooting program. It is not a reason to fetch torches and pitchforks or to complain that SELinux sucks, or any of that nonsense. Fixing the interaction between SELinux and chroot is one of those things that can only get better the more real world usage SELinux sees.
It seem to me that SELinux can provide for the same (or better) "features" of chroot without actually requiring a chrooted environment. So shouldn't we simply provide targeted policies and not use chroot for known services ?
That wouldn't work. You shouldn't rely on SELinux but only take advantage of it if it is enabled.
Rahul
On Tue, Jan 22, 2008 at 01:04:26PM -0500, Simo Sorce wrote:
On Tue, 2008-01-22 at 13:01 -0500, Yaakov Nemoy wrote:
On Jan 22, 2008 12:16 PM, Jeff Spaleta jspaleta@gmail.com wrote:
Selinux when interacting with any chroot-like apparatus is still a problem. Perhaps its time to take stock of all the packages that rely on chroot-like behavior which are similarly affected by selinux, so that a common technical solution can be found and applied.
+1
This is just a bug between SELinux and any chrooting program. It is not a reason to fetch torches and pitchforks or to complain that SELinux sucks, or any of that nonsense. Fixing the interaction between SELinux and chroot is one of those things that can only get better the more real world usage SELinux sees.
It seem to me that SELinux can provide for the same (or better) "features" of chroot without actually requiring a chrooted environment. So shouldn't we simply provide targeted policies and not use chroot for known services ?
You miss the point.
Things like pungi, mock, livecd-creator... Their whole existence in life relies heavily on creating a chroot to do their business.
This is not a problem we can just say "dont do that", it needs to be fixed, as mentioned by other posters. -- Michael
On Tue, 2008-01-22 at 16:23 -0600, Michael E Brown wrote:
On Tue, Jan 22, 2008 at 01:04:26PM -0500, Simo Sorce wrote:
On Tue, 2008-01-22 at 13:01 -0500, Yaakov Nemoy wrote:
On Jan 22, 2008 12:16 PM, Jeff Spaleta jspaleta@gmail.com wrote:
Selinux when interacting with any chroot-like apparatus is still a problem. Perhaps its time to take stock of all the packages that rely on chroot-like behavior which are similarly affected by selinux, so that a common technical solution can be found and applied.
+1
This is just a bug between SELinux and any chrooting program. It is not a reason to fetch torches and pitchforks or to complain that SELinux sucks, or any of that nonsense. Fixing the interaction between SELinux and chroot is one of those things that can only get better the more real world usage SELinux sees.
It seem to me that SELinux can provide for the same (or better) "features" of chroot without actually requiring a chrooted environment. So shouldn't we simply provide targeted policies and not use chroot for known services ?
You miss the point.
Things like pungi, mock, livecd-creator... Their whole existence in life relies heavily on creating a chroot to do their business.
This is not a problem we can just say "dont do that", it needs to be fixed, as mentioned by other posters.
And you come in late :-) Already apologized in another mail.
Simo.
Jeff Spaleta wrote:
On Jan 22, 2008 7:52 AM, Casey Dahlin cjdahlin@ncsu.edu wrote:
We're advertising it in a very public way. More people are expecting it to work.
But we aren't using it internally, we aren't dogfooding it with our spins, and I want to make sure Valent and anyone reading the thread understands that. My reading of Valent's comment informed me that he was assuming we were seeing these problems as part of spin release and implied an assumption that we were using revisor. We aren't.
Now that being said, I think any spin generation toolchain which we are offering, should be packaged in a way that informs people that selinux needs to be disabled to use correctly. And since I don't think spin creation falls into a desktop usage case of any rational merit, but falls instead into development usage, then I don't think such a tool should automatically disable selinux even temporarily.
Selinux when interacting with any chroot-like apparatus is still a problem.
Except for perhaps *cough* qfakeroot
(disclaimer: the below urls are about 12 hours old, and the tools in question are still a couple days away from being actually testable from the tutorial which also is only about 12 hours old)
http://filteredperception.org/smiley/projects/viros/viros-0.5/tools/scripts/...
http://filteredperception.org/smiley/projects/viros/docs/faq/index.html#viro...
Note, that one reason I went down this rather convoluted non-traditional architecture for a compose tool, was to quite explicitly not have any dependence on host build system state such as selinux (and not require root priveleges to run is the other related big one)
-dmc
Perhaps its time to take stock of all the packages that rely
on chroot-like behavior which are similarly affected by selinux, so that a common technical solution can be found and applied.
-jef -jef
On Tue, 22 Jan 2008 13:29:03 +0100 "Valent Turkovic" valent.turkovic@gmail.com wrote:
I tested revisor and wanted to make an up to date version of Fedora 8 Live CD - but selinux put a stop to that.
Selinux is not going to work at all for things like revisor (and pungi/livecd-creator). Both make use of chroots to install packages into, and in certain cases you can wind up causing lots of harm to your host system (installing a new policy in the chroot will actually cause that policy to activate on the running kernel and then you have policy that doesn't match labels, watch the fun!).
It is strongly recommended that you disable SELinux or at least put it in permissive if you're going to be doing composes.
Jesse Keating wrote:
On Tue, 22 Jan 2008 13:29:03 +0100 "Valent Turkovic" valent.turkovic@gmail.com wrote:
I tested revisor and wanted to make an up to date version of Fedora 8 Live CD - but selinux put a stop to that.
Selinux is not going to work at all for things like revisor (and pungi/livecd-creator). Both make use of chroots to install packages into, and in certain cases you can wind up causing lots of harm to your host system (installing a new policy in the chroot will actually cause that policy to activate on the running kernel and then you have policy that doesn't match labels, watch the fun!).
It is strongly recommended that you disable SELinux or at least put it in permissive if you're going to be doing composes.
Would it not be possible for apps like these compose tools to use an LD_PRELOAD libselinux hack like mock used to do in order to avoid these pitfalls?
I happily use selinux in enforcing mode on my desktop and would be loathed to disable it in order to run one of these tools if I needed to do so simply because of the long time it would take to relabel my system afterwards to get it back to the state it started in. That's not to mention the obvious disadvantage from a security perspective, and the impression it gives that two of Fedora's top features (SELinux and the custom respin tools) conflict with each other.
Paul.
On Tue January 22 2008, Paul Howarth wrote:
Would it not be possible for apps like these compose tools to use an LD_PRELOAD libselinux hack like mock used to do in order to avoid these pitfalls?
Maybe it is possible to use revisor with fakeroot and fakechroot to make sure it does no harm to your system. Or maybe with e.g. lguest as a virtual machine.
Regards, Till
2008/1/22 Jesse Keating jkeating@redhat.com:
On Tue, 22 Jan 2008 13:29:03 +0100 "Valent Turkovic" valent.turkovic@gmail.com wrote:
I tested revisor and wanted to make an up to date version of Fedora 8 Live CD - but selinux put a stop to that.
Selinux is not going to work at all for things like revisor (and pungi/livecd-creator). Both make use of chroots to install packages into, and in certain cases you can wind up causing lots of harm to your host system (installing a new policy in the chroot will actually cause that policy to activate on the running kernel and then you have policy that doesn't match labels, watch the fun!).
It is strongly recommended that you disable SELinux or at least put it in permissive if you're going to be doing composes.
Is there a was to make selinux aware of that or atleast put a notification window saying that you need to disable selinux in order to use revisor? One more issue for removing selinux as I said in an earlier thread :) Selinux breaks features by desing and in a bad way, and I as a user see more trouble from selinux than it is worth (just MHO).
Valent.
Valent Turkovic wrote:
2008/1/22 Jesse Keating jkeating@redhat.com:
On Tue, 22 Jan 2008 13:29:03 +0100 "Valent Turkovic" valent.turkovic@gmail.com wrote:
I tested revisor and wanted to make an up to date version of Fedora 8 Live CD - but selinux put a stop to that.
Selinux is not going to work at all for things like revisor (and pungi/livecd-creator). Both make use of chroots to install packages into, and in certain cases you can wind up causing lots of harm to your host system (installing a new policy in the chroot will actually cause that policy to activate on the running kernel and then you have policy that doesn't match labels, watch the fun!).
It is strongly recommended that you disable SELinux or at least put it in permissive if you're going to be doing composes.
Is there a was to make selinux aware of that or atleast put a notification window saying that you need to disable selinux in order to use revisor? One more issue for removing selinux as I said in an earlier thread :) Selinux breaks features by desing and in a bad way, and I as a user see more trouble from selinux than it is worth (just MHO).
Valent.
This all started when open source coders heard proprietary vendors insisting bugs were features, and they got so sick of it that in retaliation they wrote a program to insist that features were bugs :)
selinux is a good thing, but the problem is most of the time users aren't aware of it when its working properly. Few users are ever going to see selinux stop a real vulnerability. That's just the nature of the vulnerabilities themselves. They're rare.
--CJD
Valent Turkovic wrote:
2008/1/22 Jesse Keating jkeating@redhat.com:
On Tue, 22 Jan 2008 13:29:03 +0100 "Valent Turkovic" valent.turkovic@gmail.com wrote:
I tested revisor and wanted to make an up to date version of Fedora 8 Live CD - but selinux put a stop to that.
Selinux is not going to work at all for things like revisor (and pungi/livecd-creator). Both make use of chroots to install packages into, and in certain cases you can wind up causing lots of harm to your host system (installing a new policy in the chroot will actually cause that policy to activate on the running kernel and then you have policy that doesn't match labels, watch the fun!).
It is strongly recommended that you disable SELinux or at least put it in permissive if you're going to be doing composes.
Is there a was to make selinux aware of that or atleast put a notification window saying that you need to disable selinux in order to use revisor?
Revisor could be aware of SELinux and provide a warning, SELinux cannot do this.
One more issue for removing selinux as I said in an earlier thread :) Selinux breaks features by desing and in a bad way, and I as a user see more trouble from selinux than it is worth (just MHO).
Your dissatisfaction with SELinux has been duly noted by the list, you are free to disable it. However, we would prefer contributions to make the distribution more robust and smooth out the bumps rather than disabling the technology. Your choice.
John Dennis wrote:
Valent Turkovic wrote:
2008/1/22 Jesse Keating jkeating@redhat.com:
On Tue, 22 Jan 2008 13:29:03 +0100 "Valent Turkovic" valent.turkovic@gmail.com wrote:
I tested revisor and wanted to make an up to date version of Fedora 8 Live CD - but selinux put a stop to that.
Selinux is not going to work at all for things like revisor (and pungi/livecd-creator). Both make use of chroots to install packages into, and in certain cases you can wind up causing lots of harm to your host system (installing a new policy in the chroot will actually cause that policy to activate on the running kernel and then you have policy that doesn't match labels, watch the fun!).
It is strongly recommended that you disable SELinux or at least put it in permissive if you're going to be doing composes.
Is there a was to make selinux aware of that or atleast put a notification window saying that you need to disable selinux in order to use revisor?
Revisor could be aware of SELinux and provide a warning, SELinux cannot do this.
One more issue for removing selinux as I said in an earlier thread :) Selinux breaks features by desing and in a bad way, and I as a user see more trouble from selinux than it is worth (just MHO).
Your dissatisfaction with SELinux has been duly noted by the list, you are free to disable it. However, we would prefer contributions to make the distribution more robust and smooth out the bumps rather than disabling the technology. Your choice.
I started to like selinux because all of you great fedora devels said nothing but praises for it, but still it seams that any "feature" I test seams to break because of selinux.
But don't worry you all convinced me that selinux has a good reason to stay.
Valent.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Valent Turkovic wrote:
John Dennis wrote:
Valent Turkovic wrote:
2008/1/22 Jesse Keating jkeating@redhat.com:
On Tue, 22 Jan 2008 13:29:03 +0100 "Valent Turkovic" valent.turkovic@gmail.com wrote:
I tested revisor and wanted to make an up to date version of Fedora 8 Live CD - but selinux put a stop to that.
Selinux is not going to work at all for things like revisor (and pungi/livecd-creator). Both make use of chroots to install packages into, and in certain cases you can wind up causing lots of harm to your host system (installing a new policy in the chroot will actually cause that policy to activate on the running kernel and then you have policy that doesn't match labels, watch the fun!).
It is strongly recommended that you disable SELinux or at least put it in permissive if you're going to be doing composes.
Is there a was to make selinux aware of that or atleast put a notification window saying that you need to disable selinux in order to use revisor?
Revisor could be aware of SELinux and provide a warning, SELinux cannot do this.
One more issue for removing selinux as I said in an earlier thread :) Selinux breaks features by desing and in a bad way, and I as a user see more trouble from selinux than it is worth (just MHO).
Your dissatisfaction with SELinux has been duly noted by the list, you are free to disable it. However, we would prefer contributions to make the distribution more robust and smooth out the bumps rather than disabling the technology. Your choice.
I started to like selinux because all of you great fedora devels said nothing but praises for it, but still it seams that any "feature" I test seams to break because of selinux.
But don't worry you all convinced me that selinux has a good reason to stay.
Valent.
As Jesse stated earlier, using SELinux on a machine where you are going to use a chroot and install packages without using a virtual machine currently will not work. You are using the same kernel for both the chroot and the host machine, so when a package loads new policy in the chroot (selinux-policy-*rpm) the new policy will effect the host machine. For example if you are building a Fedora 7 livecd on a Fedora 8 host machine, when the new selinux-policy package gets installed the Fedora 7 policy will load and replace the Fedora 8 policy. This will invalidate any contexts that existed in Fedora 8 and not in Fedora 7 causing them to become unlabeled_t. If this happens to a process, the process usually goes wild. We (SELinux engineering) is working on some solutions, but don't have a good one now.
Virtual machines? Getting the chroot to run with a different kernel. Faking out /selinux in chroot to do nothing on policy load? Trying to stop Transitions?
On Thu January 24 2008, Daniel J Walsh wrote:
machine. For example if you are building a Fedora 7 livecd on a Fedora 8 host machine, when the new selinux-policy package gets installed the Fedora 7 policy will load and replace the Fedora 8 policy. This will invalidate any contexts that existed in Fedora 8 and not in Fedora 7 causing them to become unlabeled_t. If this happens to a process, the process usually goes wild. We (SELinux engineering) is working on some solutions, but don't have a good one now.
Virtual machines? Getting the chroot to run with a different kernel. Faking out /selinux in chroot to do nothing on policy load? Trying to stop Transitions?
Imho it would be nice if it was possible to mark (label) a directory from the outside to be the root of the chroot. Then everything within the chroot directory should have a label for the outside selinux and a label for the inside selinux. The selinus from the outside should allow everything within the chroot to to whatever it wants within the chroot (this could be configure within the policy), but should restrict access to everything outside the chroot. The selinux within the chroot then should act like there is only the inside policy and enforce it like it was the only one.
Regards, Till
On Thu, 2008-01-24 at 17:11 +0100, Till Maas wrote:
On Thu January 24 2008, Daniel J Walsh wrote:
machine. For example if you are building a Fedora 7 livecd on a Fedora 8 host machine, when the new selinux-policy package gets installed the Fedora 7 policy will load and replace the Fedora 8 policy. This will invalidate any contexts that existed in Fedora 8 and not in Fedora 7 causing them to become unlabeled_t. If this happens to a process, the process usually goes wild. We (SELinux engineering) is working on some solutions, but don't have a good one now.
Virtual machines? Getting the chroot to run with a different kernel. Faking out /selinux in chroot to do nothing on policy load? Trying to stop Transitions?
Imho it would be nice if it was possible to mark (label) a directory from the outside to be the root of the chroot. Then everything within the chroot directory should have a label for the outside selinux and a label for the inside selinux. The selinus from the outside should allow everything within the chroot to to whatever it wants within the chroot (this could be configure within the policy), but should restrict access to everything outside the chroot. The selinux within the chroot then should act like there is only the inside policy and enforce it like it was the only one.
I think it would be a property of the chroot'd process and its descendants, not of the directory, as processes operating non-chroot'd may still access the contents of that directory and should still be handled by the host policy. So a per-task policy attribute that would usually always refer to the host/global policy, but could be unshared and then have a private policy loaded for it and its descendants.
The main problem is detecting and handling accesses that cross the policy boundary (non-chroot'd process attempts to access file within the directory, chroot'd process manages to break out of the chroot and attempts to access file outside of chroot).
On Thu January 24 2008, Stephen Smalley wrote:
I think it would be a property of the chroot'd process and its descendants, not of the directory, as processes operating non-chroot'd may still access the contents of that directory and should still be handled by the host policy. So a per-task policy attribute that would
Yes, I did not think about this direction.
usually always refer to the host/global policy, but could be unshared and then have a private policy loaded for it and its descendants.
The main problem is detecting and handling accesses that cross the policy boundary (non-chroot'd process attempts to access file within the directory, chroot'd process manages to break out of the chroot and attempts to access file outside of chroot).
When there were different "namespaces" for the inner and outer selinux, then the outer selinux could handle the access trough the chroot bondary using the normal host namespace and the inner selinux would only handle the access within the chroot, using its own namespace.
Regards, Till
On Thu, Jan 24, 2008 at 05:48:20PM +0100, Till Maas wrote:
The main problem is detecting and handling accesses that cross the policy boundary (non-chroot'd process attempts to access file within the directory, chroot'd process manages to break out of the chroot and attempts to access file outside of chroot).
When there were different "namespaces" for the inner and outer selinux, then the outer selinux could handle the access trough the chroot bondary using the normal host namespace and the inner selinux would only handle the access within the chroot, using its own namespace.
What do you do if the outside namespace wants to label a file differently than the inner namespace? Create separate namespaces for the on-disk xattrs?
On Thu January 24 2008, Chuck Anderson wrote:
What do you do if the outside namespace wants to label a file differently than the inner namespace? Create separate namespaces for the on-disk xattrs?
Yes, this is what I meant with different namespaces, seperate namespaces for the xattrs within the filesystem should be used. Maybe specifying the namespace for the labels of the inner selinux should be an option for chroot then. And it should be the normal situation that the labels differ, because the outside policy should more or less allow everthing for stuff inside the chroot directory, but the inside policy would enforce more restrictions.
Regards, Till
On Thu, 24 Jan 2008, Daniel J Walsh wrote:
Virtual machines?
Something to consider perhaps is the use of lguest, which is currently i386 only, but does boot up nearly instantaneously, and can be scripted, as its console is the launching shell.
Is there an efficient technique for mounting a disk image so that changes made to it are discarded?
- James
On Fri, Jan 25, 2008 at 09:52:50AM +1100, James Morris wrote:
On Thu, 24 Jan 2008, Daniel J Walsh wrote:
Virtual machines?
Something to consider perhaps is the use of lguest, which is currently i386 only, but does boot up nearly instantaneously, and can be scripted, as its console is the launching shell.
Is there an efficient technique for mounting a disk image so that changes made to it are discarded?
Sure, just create an LVM writable snapshot of your master image, and boot with that instead, and throw away the snapshot when you're done.
Dan.
On Thu, 24 Jan 2008, Daniel P. Berrange wrote:
Something to consider perhaps is the use of lguest, which is currently i386 only, but does boot up nearly instantaneously, and can be scripted, as its console is the launching shell.
Is there an efficient technique for mounting a disk image so that changes made to it are discarded?
Sure, just create an LVM writable snapshot of your master image, and boot with that instead, and throw away the snapshot when you're done.
Cool. So if there was a RPM package which contained a barebones Fedora image and some management scripts, I don't imagine it would be too difficult to do things like build RPMs inside that with e.g. different SELinux policies to the host. Any supporting RPMS required inside the guest could be installed via a script either from host media or over the net, then the final RPM (or whatever is being created) could be copied back out to the host before discarding the guest instance.
It would not be as fast or simple as chroot, but I suspect it would work pretty well, especially if the guest dispenses with all non-essential startup.
- James
On Fri, Jan 25, 2008 at 10:17:05AM +1100, James Morris wrote:
On Thu, 24 Jan 2008, Daniel P. Berrange wrote:
Something to consider perhaps is the use of lguest, which is currently i386 only, but does boot up nearly instantaneously, and can be scripted, as its console is the launching shell.
Is there an efficient technique for mounting a disk image so that changes made to it are discarded?
Sure, just create an LVM writable snapshot of your master image, and boot with that instead, and throw away the snapshot when you're done.
Cool. So if there was a RPM package which contained a barebones Fedora image and some management scripts, I don't imagine it would be too difficult to do things like build RPMs inside that with e.g. different SELinux policies to the host. Any supporting RPMS required inside the guest could be installed via a script either from host media or over the net, then the final RPM (or whatever is being created) could be copied back out to the host before discarding the guest instance.
It would not be as fast or simple as chroot, but I suspect it would work pretty well, especially if the guest dispenses with all non-essential startup.
Actually you can do some tricks here too. You can boot the guest using the real disk image. Once it is up & running in desired state you can save the VM to disk (cf hibernate). Launching it just becomes a case of taking a snapshot of the disk, and restoring the VM state file. Much much quicker than normal startup - a matter of seconds - depending on guest RAM size. As long as you take care to always restore it against a snapshot of the disk from the same it was saved, you can repeat this restore process many times over. It is not entirely straightforward to do these steps in the general case, but if you want to mandate LVM storage only then it is a tractable problem
Dan.
On Thu, 24 Jan 2008 23:24:17 +0000 "Daniel P. Berrange" berrange@redhat.com wrote:
On Fri, Jan 25, 2008 at 10:17:05AM +1100, James Morris wrote:
On Thu, 24 Jan 2008, Daniel P. Berrange wrote:
Something to consider perhaps is the use of lguest, which is currently i386 only, but does boot up nearly instantaneously, and can be scripted, as its console is the launching shell.
Is there an efficient technique for mounting a disk image so that changes made to it are discarded?
Sure, just create an LVM writable snapshot of your master image, and boot with that instead, and throw away the snapshot when you're done.
Cool. So if there was a RPM package which contained a barebones Fedora image and some management scripts, I don't imagine it would be too difficult to do things like build RPMs inside that with e.g. different SELinux policies to the host. Any supporting RPMS required inside the guest could be installed via a script either from host media or over the net, then the final RPM (or whatever is being created) could be copied back out to the host before discarding the guest instance.
It would not be as fast or simple as chroot, but I suspect it would work pretty well, especially if the guest dispenses with all non-essential startup.
Actually you can do some tricks here too. You can boot the guest using the real disk image. Once it is up & running in desired state you can save the VM to disk (cf hibernate). Launching it just becomes a case of taking a snapshot of the disk, and restoring the VM state file. Much much quicker than normal startup - a matter of seconds - depending on guest RAM size. As long as you take care to always restore it against a snapshot of the disk from the same it was saved, you can repeat this restore process many times over. It is not entirely straightforward to do these steps in the general case, but if you want to mandate LVM storage only then it is a tractable problem
Dan.
Yeah, it all sounds pretty exciting, but get back to me when it works on x86_64, ppc, ppc64, ia64, s390, s390x, sparc, sparc64, arm, alpha...
Jesse Keating wrote:
On Thu, 24 Jan 2008 23:24:17 +0000 "Daniel P. Berrange" berrange@redhat.com wrote:
On Fri, Jan 25, 2008 at 10:17:05AM +1100, James Morris wrote:
On Thu, 24 Jan 2008, Daniel P. Berrange wrote:
Something to consider perhaps is the use of lguest, which is currently i386 only, but does boot up nearly instantaneously, and can be scripted, as its console is the launching shell.
Is there an efficient technique for mounting a disk image so that changes made to it are discarded?
Sure, just create an LVM writable snapshot of your master image, and boot with that instead, and throw away the snapshot when you're done.
Cool. So if there was a RPM package which contained a barebones Fedora image and some management scripts, I don't imagine it would be too difficult to do things like build RPMs inside that with e.g. different SELinux policies to the host. Any supporting RPMS required inside the guest could be installed via a script either from host media or over the net, then the final RPM (or whatever is being created) could be copied back out to the host before discarding the guest instance.
It would not be as fast or simple as chroot, but I suspect it would work pretty well, especially if the guest dispenses with all non-essential startup.
Actually you can do some tricks here too. You can boot the guest using the real disk image. Once it is up & running in desired state you can save the VM to disk (cf hibernate). Launching it just becomes a case of taking a snapshot of the disk, and restoring the VM state file. Much much quicker than normal startup - a matter of seconds - depending on guest RAM size. As long as you take care to always restore it against a snapshot of the disk from the same it was saved, you can repeat this restore process many times over. It is not entirely straightforward to do these steps in the general case, but if you want to mandate LVM storage only then it is a tractable problem
Dan.
Yeah, it all sounds pretty exciting, but get back to me when it works on x86_64, ppc, ppc64, ia64, s390, s390x, sparc, sparc64, arm, alpha...
*cough* viros *cough* smirfgen *cough* qfakeroot
No, doesn't work on those archs, by since all the infra is qemu, it may well get there in the foreseeable future.
Basically smirfgen is my version of mkinitrd/mayflower, but in addition to generating initramfss that boot livecds, it generates ones which do nothing but set up sandbox so that qfakeroot can boot them up via qemu attached to one disk image used for input, one used for output (gets detarred), and one for scratch space, and one to optionally connect to a real disk device or image. There is also an option to automatically make that last one get a devicemapper snapshot layer of protection (same thing as the lvm described, but at a lower more generic layer).
And qemu gets used in nographic with console going to tty which goes to stdout (redirected internally).
The result is that it takes about a couple minutes to convert an arbitrary tarball to an ext3 filesystem image. (longer for bigger input)
Currently it pulls in a copy of the host's selinux policy to use, though it is pretty trivial to make that an option to disable, or pull in an arbitrary selinux policy.
Still very alpha, but maybe interesting to consider
-dmc
On Thu, 24 Jan 2008 18:18:26 -0600 Douglas McClendon dmc.fedora@filteredperception.org wrote:
*cough* viros *cough* smirfgen *cough* qfakeroot
No, doesn't work on those archs, by since all the infra is qemu, it may well get there in the foreseeable future.
I've been waiting for qemu to work on ppc, the simple case right? Still waiting...
Jesse Keating wrote:
On Thu, 24 Jan 2008 18:18:26 -0600 Douglas McClendon dmc.fedora@filteredperception.org wrote:
*cough* viros *cough* smirfgen *cough* qfakeroot
No, doesn't work on those archs, by since all the infra is qemu, it may well get there in the foreseeable future.
I've been waiting for qemu to work on ppc, the simple case right? Still waiting...
???
http://fabrice.bellard.free.fr/qemu/status.html
-dmc
On Thu, 24 Jan 2008 18:47:56 -0600 Douglas McClendon dmc.fedora@filteredperception.org wrote:
???
You can't boot an OS in it, you can only run some binaries in it.
On Thu, Jan 24, 2008 at 06:18:26PM -0600, Douglas McClendon wrote:
Jesse Keating wrote:
On Thu, 24 Jan 2008 23:24:17 +0000 "Daniel P. Berrange" berrange@redhat.com wrote:
On Fri, Jan 25, 2008 at 10:17:05AM +1100, James Morris wrote:
On Thu, 24 Jan 2008, Daniel P. Berrange wrote:
Something to consider perhaps is the use of lguest, which is currently i386 only, but does boot up nearly instantaneously, and can be scripted, as its console is the launching shell.
Is there an efficient technique for mounting a disk image so that changes made to it are discarded?
Sure, just create an LVM writable snapshot of your master image, and boot with that instead, and throw away the snapshot when you're done.
Cool. So if there was a RPM package which contained a barebones Fedora image and some management scripts, I don't imagine it would be too difficult to do things like build RPMs inside that with e.g. different SELinux policies to the host. Any supporting RPMS required inside the guest could be installed via a script either from host media or over the net, then the final RPM (or whatever is being created) could be copied back out to the host before discarding the guest instance.
It would not be as fast or simple as chroot, but I suspect it would work pretty well, especially if the guest dispenses with all non-essential startup.
Actually you can do some tricks here too. You can boot the guest using the real disk image. Once it is up & running in desired state you can save the VM to disk (cf hibernate). Launching it just becomes a case of taking a snapshot of the disk, and restoring the VM state file. Much much quicker than normal startup - a matter of seconds - depending on guest RAM size. As long as you take care to always restore it against a snapshot of the disk from the same it was saved, you can repeat this restore process many times over. It is not entirely straightforward to do these steps in the general case, but if you want to mandate LVM storage only then it is a tractable problem
Dan.
Yeah, it all sounds pretty exciting, but get back to me when it works on x86_64, ppc, ppc64, ia64, s390, s390x, sparc, sparc64, arm, alpha...
*cough* viros *cough* smirfgen *cough* qfakeroot
No, doesn't work on those archs, by since all the infra is qemu, it may well get there in the foreseeable future.
Plain QEMU is unusably slow for doing any real work - particularly compute and disk intensive stuff like builds / composes. You need KVM for it to be viable, which restricts you to i686 / x86_64 currently, and possibly adding ia64 & ppc64 in the medium-term future. No work on sparc/arm, and no clue about s390.
Dan.
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.
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).
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".
works for me.
$0.02
-dmc
You need KVM for it to be
viable, which restricts you to i686 / x86_64 currently, and possibly adding ia64 & ppc64 in the medium-term future. No work on sparc/arm, and no clue about s390.
Dan.
On Thu, 24 Jan 2008 18:59:47 -0600 Douglas McClendon dmc.fedora@filteredperception.org wrote:
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).
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".
Eh, if we really wanted to do this, we'd just re-kickstart the builder each time we wanted to do a build, and then just do the build in the freshly kickstart install, removing it when done.
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'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. 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.
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.
Dan.
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
On Thu, 24 Jan 2008 19:49:42 -0600 Douglas McClendon dmc.fedora@filteredperception.org wrote:
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.
Maybe I missed that, but every /rpm/ is buildable by non-root. It's when you start talking about /composing/ releases and Live images that root privs are needed (or enoug privs to make loopback devices).
Now, we could do something more sneaky and ship the livcd-creator and pungi python scripts setuid, but that's probably not what you're looking for.
Jesse Keating wrote:
On Thu, 24 Jan 2008 19:49:42 -0600 Douglas McClendon dmc.fedora@filteredperception.org wrote:
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.
Maybe I missed that, but every /rpm/ is buildable by non-root. It's when you start talking about /composing/ releases and Live images that root privs are needed (or enoug privs to make loopback devices).
I did miss that (had thought that the anaconda rpm was spinning some disk images). But my target was recompiling every line of fedora source code into a new fedora release (isos too), without requiring root privs. I.e. that was the itch I wanted to scratch, and so the distinction between rpms and compose tools doesn't change the issue for me.
Now, we could do something more sneaky and ship the livcd-creator and pungi python scripts setuid, but that's probably not what you're looking for.
Correct. Nor a magical hal/dbus/whatever service that exposes some root capabilities.
But again, I'm not suggesting that there aren't a few viable theoretical alternatives to the method I presented. Though I don't know of any that work already. But as you said, sure, you can just go suid and do whatever you want. I just am kind of proud of the fact that I can accomplish the task without root/suid.
Along with as described, the relative ease of doing a very small containered alternate-selinux policy set up. It sort of sounded to me like a useful solution for the selinux-chroot issues brought up in this thread.
I was disappointed googling and seeing your issues with qemu-ppc not being great for booting up full blown fedora-ppc. I too really hope that sees improvement soon.
-dmc
On Thu, 24 Jan 2008 20:27:05 -0600 Douglas McClendon dmc.fedora@filteredperception.org wrote:
But again, I'm not suggesting that there aren't a few viable theoretical alternatives to the method I presented. Though I don't know of any that work already. But as you said, sure, you can just go suid and do whatever you want. I just am kind of proud of the fact that I can accomplish the task without root/suid.
That is pretty cool that you were able to accomplish that, even if it does take a long time to do.
Along with as described, the relative ease of doing a very small containered alternate-selinux policy set up. It sort of sounded to me like a useful solution for the selinux-chroot issues brought up in this thread.
I was disappointed googling and seeing your issues with qemu-ppc not being great for booting up full blown fedora-ppc. I too really hope that sees improvement soon.
I do too, but honestly it didn't seem like many people out there that A) had the knowledge necessary to fix it and B) were willing / interested / had time to work on it. It would certainly make the things you're trying to do easier, and it would vastly improve my ability to test out the composes I'm doing.
2008/1/24 Jesse Keating jkeating@redhat.com:
Maybe I missed that, but every /rpm/ is buildable by non-root. It's when you start talking about /composing/ releases and Live images that root privs are needed (or enoug privs to make loopback devices).
make loopback devices.... does fuse provide a non-root way to deal with this here?
-jef
On Thu, 24 Jan 2008 20:14:54 -0900 "Jeff Spaleta" jspaleta@gmail.com wrote:
make loopback devices.... does fuse provide a non-root way to deal with this here?
Probably through some setuid crud.
Jeff Spaleta wrote:
2008/1/24 Jesse Keating jkeating@redhat.com:
Maybe I missed that, but every /rpm/ is buildable by non-root. It's when you start talking about /composing/ releases and Live images that root privs are needed (or enoug privs to make loopback devices).
make loopback devices.... does fuse provide a non-root way to deal with this here?
I think there are historical threads about the security/code-quality and how it related to the decision of requiring root to add users to the fuse group. Sounded like fuse might get the job done someday, but someday wasn't quite here yet.
Still, for doing composes as non-root I like my qemu 'qfakeroot', as it handles everything nicely (but slowly). I.e. I imagine running into headaches getting rpm post scripts running as non-root in a target dir, using something like traditional fakeroot to deal with file ownerships. And of course coming full circle, then there would still be the selinux issues in this non-root fuse-using quasi-chroot hypothetical compose beast...
-dmc
Douglas McClendon wrote:
Jeff Spaleta wrote:
2008/1/24 Jesse Keating jkeating@redhat.com:
Maybe I missed that, but every /rpm/ is buildable by non-root. It's when you start talking about /composing/ releases and Live images that root privs are needed (or enoug privs to make loopback devices).
make loopback devices.... does fuse provide a non-root way to deal with this here?
I think there are historical threads about the security/code-quality and how it related to the decision of requiring root to add users to the fuse group. Sounded like fuse might get the job done someday, but someday wasn't quite here yet.
Still, for doing composes as non-root I like my qemu 'qfakeroot', as it handles everything nicely (but slowly). I.e. I imagine running into
What still prevents kqemu module being shipped with fedora? That speeds things tremendously!
Valent.
On Fri, Jan 25, 2008 at 02:27:12PM +0100, Valent Turkovic wrote:
Douglas McClendon wrote:
Jeff Spaleta wrote:
2008/1/24 Jesse Keating jkeating@redhat.com:
Maybe I missed that, but every /rpm/ is buildable by non-root. It's when you start talking about /composing/ releases and Live images that root privs are needed (or enoug privs to make loopback devices).
make loopback devices.... does fuse provide a non-root way to deal with this here?
I think there are historical threads about the security/code-quality and how it related to the decision of requiring root to add users to the fuse group. Sounded like fuse might get the job done someday, but someday wasn't quite here yet.
Still, for doing composes as non-root I like my qemu 'qfakeroot', as it handles everything nicely (but slowly). I.e. I imagine running into
What still prevents kqemu module being shipped with fedora? That speeds things tremendously!
It is buggy as hell and no one is actively working on fixing it, and it is not guarenteed secure
Dan.
Daniel P. Berrange wrote:
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.
Forgot to reply to this piece, which is quite relevant.
What I'm doing is precisely that- but much less, and 100% automated. Instead of using a throwaway kickstarted host, I'm using a throwaway initramfs that has the minimal files needed to losetup/loadpolicy/mkfs/chroot. (and seperately boot rescue iso and do an http install from an http server running as the same user running qemu)
And by doing it in qemu, I can do all of this with a command-line, run as non-root, perhaps on a headless remote server running centos/rhel, that if it had a soul, would feel slightly dirty having had hundreds of fedora rpms installed as root under a chroot.
No doubt xen can be coaxed to do the same thing, but again, I love the simplicity and flexibility of qemu.
-dmc