selinux breaks revisor

[Valent Turkovic]

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%20browse...
http://www.uploadgeek.com/uploads456/0/Screenshot-setroubleshoot%20browse...

Cheers,
Valent.

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

[Lubomir Kundrak]

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%20browse...
>  http://www.uploadgeek.com/uploads456/0/Screenshot-setroubleshoot%20browse...
Valent, please report to Bugzilla.
Please.

Thanks,
-- 
Lubomir Kundrak (Red Hat Security Response Team)

[Valent Turkovic]

On Jan 22, 2008 1:38 PM, Lubomir Kundrak <lkundrak(a)redhat.com&gt; 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%20browse...
>  >
> http://www.uploadgeek.com/uploads456/0/Screenshot-setroubleshoot%20browse...
>
>  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.

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

[Valent Turkovic]

On Jan 22, 2008 2:16 PM, Valent Turkovic <valent.turkovic(a)gmail.com&gt; wrote:
>  On Jan 22, 2008 1:38 PM, Lubomir Kundrak <lkundrak(a)redhat.com&gt;
> 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%20browse...
>  > >
> http://www.uploadgeek.com/uploads456/0/Screenshot-setroubleshoot%20browse...
>  >
>  > 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

[Benjamin Kreuter]

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

[Valent Turkovic]

2008/1/22 Benjamin Kreuter <ben.kreuter(a)gmail.com&gt;:
>  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%20browse...

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.


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

[Benjamin Kreuter]

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

[Valent Turkovic]

2008/1/22 Benjamin Kreuter <ben.kreuter(a)gmail.com&gt;:
>  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(a)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://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

[Valent Turkovic]

On Jan 22, 2008 3:22 PM, Valent Turkovic <valent.turkovic(a)gmail.com&gt; wrote:
>  2008/1/22 Benjamin Kreuter <ben.kreuter(a)gmail.com&gt;:
>
>  > 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(a)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%20browse...

third time is the charm :)

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

[Laurent Rineau]

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.

-- 
Laurent Rineau
http://fedoraproject.org/wiki/LaurentRineau

[John Dennis]

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%20browse...
>  http://www.uploadgeek.com/uploads456/0/Screenshot-setroubleshoot%20browse...
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(a)redhat.com&gt;

[Valent Turkovic]

On Jan 22, 2008 2:05 PM, John Dennis <jdennis(a)redhat.com&gt; 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%20browse...
>  >
> http://www.uploadgeek.com/uploads456/0/Screenshot-setroubleshoot%20browse...
>
>  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(a)redhat.com&gt; 
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.



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

[Rahul Sundaram]

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

[Jef Spaleta]

On Jan 22, 2008 4:18 AM, Valent Turkovic <valent.turkovic(a)gmail.com&gt; 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

[Casey Dahlin]

Jeff Spaleta wrote:
>  On Jan 22, 2008 4:18 AM, Valent Turkovic
> <valent.turkovic(a)gmail.com&gt; 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

[Jesse Keating]

On Tue, 22 Jan 2008 11:52:00 -0500
Casey Dahlin <cjdahlin(a)ncsu.edu&gt; 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 (:

-- 
Jesse Keating
Fedora -- All my bits are free, are yours?

[Jef Spaleta]

On Jan 22, 2008 7:52 AM, Casey Dahlin <cjdahlin(a)ncsu.edu&gt; 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

[Yaakov Nemoy]

On Jan 22, 2008 12:16 PM, Jeff Spaleta <jspaleta(a)gmail.com&gt; 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

[Simo Sorce]

On Tue, 2008-01-22 at 13:01 -0500, Yaakov Nemoy wrote:
>  On Jan 22, 2008 12:16 PM, Jeff Spaleta <jspaleta(a)gmail.com&gt;
> 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.

-- 
| Simo S Sorce |
| Sr.Soft.Eng. |
| Red Hat, Inc |
| New York, NY |

[Jef Spaleta]

On Jan 22, 2008 9:04 AM, Simo Sorce <ssorce(a)redhat.com&gt; 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

[Yaakov Nemoy]

On Jan 22, 2008 1:04 PM, Simo Sorce <ssorce(a)redhat.com&gt; wrote:
>  On Tue, 2008-01-22 at 13:01 -0500, Yaakov Nemoy wrote:
>  > On Jan 22, 2008 12:16 PM, Jeff Spaleta <jspaleta(a)gmail.com&gt; 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

[Jesse Keating]

On Tue, 22 Jan 2008 13:04:26 -0500
Simo Sorce <ssorce(a)redhat.com&gt; 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.

-- 
Jesse Keating
Fedora -- All my bits are free, are yours?

[Simo Sorce]

On Tue, 2008-01-22 at 13:14 -0500, Jesse Keating wrote:
>  On Tue, 22 Jan 2008 13:04:26 -0500
>  Simo Sorce <ssorce(a)redhat.com&gt; 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 S Sorce |
| Sr.Soft.Eng. |
| Red Hat, Inc |
| New York, NY |

[Rahul Sundaram]

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(a)gmail.com&gt; 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

[Michael E Brown]

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(a)gmail.com&gt; 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

[Simo Sorce]

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(a)gmail.com&gt; 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.

-- 
| Simo S Sorce |
| Sr.Soft.Eng. |
| Red Hat, Inc |
| New York, NY |

[Douglas McClendon]

Jeff Spaleta wrote:
>  On Jan 22, 2008 7:52 AM, Casey Dahlin <cjdahlin(a)ncsu.edu&gt;
> 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/scrip...

http://filteredperception.org/smiley/projects/viros/docs/faq/index.html#v...

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
>

[Jesse Keating]

On Tue, 22 Jan 2008 13:29:03 +0100
"Valent Turkovic" <valent.turkovic(a)gmail.com&gt; 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
Fedora -- All my bits are free, are yours?

[Paul Howarth]

Jesse Keating wrote:
>  On Tue, 22 Jan 2008 13:29:03 +0100
>  "Valent Turkovic" <valent.turkovic(a)gmail.com&gt; 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.

[Till Maas]

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

[Valent Turkovic]

2008/1/22 Jesse Keating <jkeating(a)redhat.com&gt;:
>  On Tue, 22 Jan 2008 13:29:03 +0100
>  "Valent Turkovic" <valent.turkovic(a)gmail.com&gt; 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.


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

[Casey Dahlin]

Valent Turkovic wrote:
>  2008/1/22 Jesse Keating <jkeating(a)redhat.com&gt;:
>    
> > On Tue, 22 Jan 2008 13:29:03 +0100
> > "Valent Turkovic" <valent.turkovic(a)gmail.com&gt; 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

[John Dennis]

Valent Turkovic wrote:
>  2008/1/22 Jesse Keating <jkeating(a)redhat.com&gt;:
> > On Tue, 22 Jan 2008 13:29:03 +0100
> > "Valent Turkovic" <valent.turkovic(a)gmail.com&gt; 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 <jdennis(a)redhat.com&gt;

[Valent Turkovic]

John Dennis wrote:
>  Valent Turkovic wrote:
> > 2008/1/22 Jesse Keating <jkeating(a)redhat.com&gt;:
> >> On Tue, 22 Jan 2008 13:29:03 +0100
> >> "Valent Turkovic" <valent.turkovic(a)gmail.com&gt; 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.

[Daniel J Walsh]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Valent Turkovic wrote:
>  John Dennis wrote:
> > Valent Turkovic wrote:
> >> 2008/1/22 Jesse Keating <jkeating(a)redhat.com&gt;:
> >>> On Tue, 22 Jan 2008 13:29:03 +0100
> >>> "Valent Turkovic" <valent.turkovic(a)gmail.com&gt; 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?

> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.8 (GNU/Linux)
> Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
>
> iEUEARECAAYFAkeYqd4ACgkQrlYvE4MpobPyMwCYwWwFtTnOQit/ENGWGGudTvGa
> mgCgkUEgkCrRDo/EVbwQq9Ax6ZCWCug=
> =Ol/k
> -----END PGP SIGNATURE-----

[Till Maas]

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

[Stephen Smalley]

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

-- 
Stephen Smalley
National Security Agency

[Till Maas]

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

[Chuck Anderson]

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?

[Till Maas]

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

[James Morris]

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
-- 
James Morris
<jmorris(a)namei.org&gt;

[Daniel P. Berrange]

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.
-- 
|=- Red Hat, Engineering, Emerging Technologies, Boston.  [phone] -=|
|=-           Perl modules: http://search.cpan.org/~danberr/              -=|
|=-               Projects: http://freshmeat.net/~danielpb/               -=|
|=-  GnuPG: 7D3B9505   F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505  -=|

[James Morris]

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
-- 
James Morris
<jmorris(a)namei.org&gt;

[Daniel P. Berrange]

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.
-- 
|=- Red Hat, Engineering, Emerging Technologies, Boston.  [phone] -=|
|=-           Perl modules: http://search.cpan.org/~danberr/              -=|
|=-               Projects: http://freshmeat.net/~danielpb/               -=|
|=-  GnuPG: 7D3B9505   F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505  -=|

[Jesse Keating]

On Thu, 24 Jan 2008 23:24:17 +0000
"Daniel P. Berrange" <berrange(a)redhat.com&gt; 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
Fedora -- All my bits are free, are yours?

[Douglas McClendon]

Jesse Keating wrote:
>  On Thu, 24 Jan 2008 23:24:17 +0000
>  "Daniel P. Berrange" <berrange(a)redhat.com&gt; 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

http://viros.org

-dmc

[Jesse Keating]

On Thu, 24 Jan 2008 18:18:26 -0600
Douglas McClendon <dmc.fedora(a)filteredperception.org&gt; 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
Fedora -- All my bits are free, are yours?

[Douglas McClendon]

Jesse Keating wrote:
>  On Thu, 24 Jan 2008 18:18:26 -0600
>  Douglas McClendon <dmc.fedora(a)filteredperception.org&gt; 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

[Jesse Keating]

On Thu, 24 Jan 2008 18:47:56 -0600
Douglas McClendon <dmc.fedora(a)filteredperception.org&gt; wrote:

>  ???
>  
>  http://fabrice.bellard.free.fr/qemu/status.html 
You can't boot an OS in it, you can only run some binaries in it.

-- 
Jesse Keating
Fedora -- All my bits are free, are yours?

[Daniel P. Berrange]

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(a)redhat.com&gt; 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.
-- 
|=- Red Hat, Engineering, Emerging Technologies, Boston.  [phone] -=|
|=-           Perl modules: http://search.cpan.org/~danberr/              -=|
|=-               Projects: http://freshmeat.net/~danielpb/               -=|
|=-  GnuPG: 7D3B9505   F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505  -=|

[Douglas McClendon]

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.

[Jesse Keating]

On Thu, 24 Jan 2008 18:59:47 -0600
Douglas McClendon <dmc.fedora(a)filteredperception.org&gt; 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.

-- 
Jesse Keating
Fedora -- All my bits are free, are yours?

[Daniel P. Berrange]

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.
-- 
|=- Red Hat, Engineering, Emerging Technologies, Boston.  [phone] -=|
|=-           Perl modules: http://search.cpan.org/~danberr/              -=|
|=-               Projects: http://freshmeat.net/~danielpb/               -=|
|=-  GnuPG: 7D3B9505   F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505  -=|

[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

[Jesse Keating]

On Thu, 24 Jan 2008 19:49:42 -0600
Douglas McClendon <dmc.fedora(a)filteredperception.org&gt; 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
Fedora -- All my bits are free, are yours?

[Douglas McClendon]

Jesse Keating wrote:
>  On Thu, 24 Jan 2008 19:49:42 -0600
>  Douglas McClendon <dmc.fedora(a)filteredperception.org&gt; 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

[Jesse Keating]

On Thu, 24 Jan 2008 20:27:05 -0600
Douglas McClendon <dmc.fedora(a)filteredperception.org&gt; 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.

-- 
Jesse Keating
Fedora -- All my bits are free, are yours?

[Jef Spaleta]

2008/1/24 Jesse Keating <jkeating(a)redhat.com&gt;:
>  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

[Jesse Keating]

On Thu, 24 Jan 2008 20:14:54 -0900
"Jeff Spaleta" <jspaleta(a)gmail.com&gt; wrote:

>  make loopback devices....  does fuse provide a non-root way to deal
>  with this here? 
Probably through some setuid crud.

-- 
Jesse Keating
Fedora -- All my bits are free, are yours?

[Douglas McClendon]

Jeff Spaleta wrote:
>  2008/1/24 Jesse Keating <jkeating(a)redhat.com&gt;:
> > 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

[Valent Turkovic]

Douglas McClendon wrote:
>  Jeff Spaleta wrote:
> > 2008/1/24 Jesse Keating <jkeating(a)redhat.com&gt;:
> >> 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.

[Rahul Sundaram]

Valent Turkovic wrote:
>  
>  What still prevents kqemu module being shipped with fedora? That speeds 
>  things tremendously! 
This question has been asked before. The module is not in the upstream 
kernel. You can check out kvm instead.

Rahul

[Daniel P. Berrange]

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(a)redhat.com&gt;:
>  >>>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.
-- 
|=- Red Hat, Engineering, Emerging Technologies, Boston.  [phone] -=|
|=-           Perl modules: http://search.cpan.org/~danberr/              -=|
|=-               Projects: http://freshmeat.net/~danielpb/               -=|
|=-  GnuPG: 7D3B9505   F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505  -=|

[Douglas McClendon]

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