From jkeating at redhat.com Tue Jan 2 19:21:36 2007 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 2 Jan 2007 14:21:36 -0500 Subject: pungi issues In-Reply-To: <45955FAA.6070305@flyingj.com> References: <45955FAA.6070305@flyingj.com> Message-ID: <200701021421.36778.jkeating@redhat.com> On Friday 29 December 2006 13:34, Phil Meyer wrote: > ... > Scrubbing trees... /tmp/treedir.29220/instimage > cp: cannot stat `/tmp/treedir.29220/instimage/boot/memtest*': No such > file or directory > mv: cannot stat > `/tmp/treedir.29220/instimage/usr/sbin/busybox.anaconda': No such file > or directory > ... > These might be an issue They're not really, you just won't be able to do memtest from the CD. > ... > Found keymap override, using it > unpacking > /big/pungi/6.89/i386/os/Fedora/kernel-2.6.18-1.2868.fc6.i586.rpm.i586 > Building initrd.img > Wrote /tmp/makebootdisk.initrdimage.7258 (5796k compressed) > Building isolinux directory > 192000 pixels, 9629 bytes, (89.97% compression) > Unknown file type (unallocated) > /big/pungi/6.89/i386/os/images/isopath/.. - ignoring and continuing. > mkdosfs 2.11 (12 Mar 2005) > cannot find package kernel-xen in path /big/pungi/6.89/i386/os/Fedora > No i586 kernel, trying i686... > unpacking > /big/pungi/6.89/i386/os/Fedora/kernel-xen-2.6.18-1.2868.fc6.i686.rpm.i686 > Building i686 guest initrd.img > Wrote /tmp/makebootdisk.initrdimage.7258 (5808k compressed) > Building minstg.img > ... > Why is the i586 image here?? Not entirely sure, but may not be a problem either. > The result is ALWAYS: > > ERROR ? : failed to mount loop: Invalid argument > ERROR ? : Error mounting /dev/loop0 on /mnt/runtime (Invalid Argument) > > This happens when using the stock /etc/pungi as shipped from extras, and > any incarnation of comps.xml that I can put together. This is due to using the kernel that was in FC6 updates, which couldn't mount squasfs images to add files to. A new kernel was put into updates yesterday that should solve this issue. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From williams at redhat.com Thu Jan 4 16:37:03 2007 From: williams at redhat.com (Clark Williams) Date: Thu, 04 Jan 2007 10:37:03 -0600 Subject: RFC: new mock: strategy, selinux, etc. Message-ID: <459D2D2F.6030107@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello all, It's been some number of months (six+) since we decided to change the way mock works. We (Michael Brown and I, with input from skvidal and others) came up with a change in how mock launches, manages permissions and runs privileged commands. Old mock (mock-0.6 and previous) is a python script that does some sanity checking (insures that the person running mock is not root and is in the mock group) and then processes the input commands. Whenever it needed to do something that required root privileges, old mock ran a setuid root program named mock-helper. Mock-helper is a C program that knows how to do a limited number of things (mount/unmount, run chroot, etc.). The new mock (mock-0.7 and beyond) turns things around a bit. In new mock, the program /usr/bin/mock is a setuid:root, setgid:mock C program that does one thing only: launches the command "python /usr/libexec/mock.py " in it's own kernel namespace. The mock.py logic still sanity checks that the user is in the mock group and drops privileges to the actual uid while keeping the gid of the process the mock group. As long as we're careful to maintain proper group ownership and permissions of created file and directories, this should go a long way toward fixing the issues we're having with multiple users on a single machine. New mock will no longer use mock-helper. When it needs to do something that requires root privileges, it will elevate it's privilege level to root (using os.setreuid()), execute the command and then drop privileges back to the normal user. All of this is working, although it has not been extensively testing (hello rawhide!). I've merged the BZ bugfixes from the mock-0.6 branch of CVS into the head (which is the new mock) and would like to push the new mock out to rawhide for testing. What I'm looking for from the readership of this list is: 1. Review of strategy and code for security issues 2. Help in formulating an SELinux plan/policy for mock We had some discussion on this issue back in June 2006, but I'd like to look at it one more time before inflicting the new mock on the rawhide faithful. With regard to SELinux, I'm not sure where we need to go with mock. I want mock to function properly and securely on a system running SELinux, but I'm just not sure how to go about that. I've looked at the steps mentioned on: http://fedoraproject.org/wiki/Extras/MockTricks But I'm too SELinux ignorant to be able to make an informed judgment on whether that's the right thing to do. Help on this would be greatly appreciated. Thanks, Clark -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFFnS0vHyuj/+TTEp0RAtmUAJ0X6axpPl9UNA8JeSYBeiT++OBtQwCg1/Vj 3NGUFzEmfw5b10NJq3LhxT0= =sIYO -----END PGP SIGNATURE----- From paul at city-fan.org Thu Jan 4 17:52:06 2007 From: paul at city-fan.org (Paul Howarth) Date: Thu, 04 Jan 2007 17:52:06 +0000 Subject: RFC: new mock: strategy, selinux, etc. In-Reply-To: <459D2D2F.6030107@redhat.com> References: <459D2D2F.6030107@redhat.com> Message-ID: <1167933126.15187.7.camel@metropolis.intra.city-fan.org> On Thu, 2007-01-04 at 10:37 -0600, Clark Williams wrote: > What I'm looking for from the readership of this list is: > > 1. Review of strategy and code for security issues > 2. Help in formulating an SELinux plan/policy for mock > > We had some discussion on this issue back in June 2006, but I'd like to > look at it one more time before inflicting the new mock on the rawhide > faithful. > > With regard to SELinux, I'm not sure where we need to go with mock. I > want mock to function properly and securely on a system running SELinux, > but I'm just not sure how to go about that. I've looked at the steps > mentioned on: > > http://fedoraproject.org/wiki/Extras/MockTricks > > But I'm too SELinux ignorant to be able to make an informed judgment on > whether that's the right thing to do. Help on this would be greatly > appreciated. The SELinux policy on the wiki does two main things: 1. Label everything under /var/lib/mock with a special SELinux context type that all processes running under mock can do as they like with. 2. Run the mock process with the ability to execute code from writable memory. This is necessary in order to support technologies such as java and mono, which are sometimes used during package builds. So basically it's the minimum necessary to get mock usable under the targeted policy. Neither of these things should be affected by the internal restructuring of mock itself. If the new mock will run OK on FC6, I can test it quite easily as both of my buildsystem machines are running FC6 with SELinux on. Paul. From Axel.Thimm at ATrpms.net Thu Jan 4 18:32:11 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Thu, 4 Jan 2007 19:32:11 +0100 Subject: RFC: new mock: strategy, selinux, etc. In-Reply-To: <459D2D2F.6030107@redhat.com> References: <459D2D2F.6030107@redhat.com> Message-ID: <20070104183211.GA4997@neu.nirvana> On Thu, Jan 04, 2007 at 10:37:03AM -0600, Clark Williams wrote: > New mock will no longer use mock-helper. When it needs to do something > that requires root privileges, it will elevate it's privilege level to > root (using os.setreuid()), execute the command and then drop privileges > back to the normal user. But isn't this a security regression towards the previous model? Previously all elevation procedures were confined and well controlled. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From williams at redhat.com Thu Jan 4 19:13:25 2007 From: williams at redhat.com (Clark Williams) Date: Thu, 04 Jan 2007 13:13:25 -0600 Subject: RFC: new mock: strategy, selinux, etc. In-Reply-To: <20070104183211.GA4997@neu.nirvana> References: <459D2D2F.6030107@redhat.com> <20070104183211.GA4997@neu.nirvana> Message-ID: <459D51D5.10202@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Axel Thimm wrote: > On Thu, Jan 04, 2007 at 10:37:03AM -0600, Clark Williams wrote: >> New mock will no longer use mock-helper. When it needs to do something >> that requires root privileges, it will elevate it's privilege level to >> root (using os.setreuid()), execute the command and then drop privileges >> back to the normal user. > > But isn't this a security regression towards the previous model? > Previously all elevation procedures were confined and well > controlled. > One of the first thing that the __init__() method for class Root does in mock.py is to call self.drop() to lower the privilege level. Thereafter, any command that new mock does as root is done via the do_elevated() method of the Root class, and any time the actual python code needs root access (e.g. the rpm library routines), it's bracketed by elevate() and drop() calls. This makes it easy to audit how the commands are used and in what context code is executed. The main reason we wanted to get rid of mock-helper is that it was non-trivial C code and the thought was to limit the amount of work that's done at the C level. Yeah, I realize that it's easy to write bad code in Python too, but it's harder to inadvertently set up a buffer overflow situation in Python than in C. Clark -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFFnVHVHyuj/+TTEp0RAsYmAKDeX7r3eT8GWxcjLUXR/8ApknA+wQCgpKAF fDvADWjSl24DCt19MPwYwO8= =q/bR -----END PGP SIGNATURE----- From Axel.Thimm at ATrpms.net Thu Jan 4 20:06:01 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Thu, 4 Jan 2007 21:06:01 +0100 Subject: RFC: new mock: strategy, selinux, etc. In-Reply-To: <459D51D5.10202@redhat.com> References: <459D2D2F.6030107@redhat.com> <20070104183211.GA4997@neu.nirvana> <459D51D5.10202@redhat.com> Message-ID: <20070104200601.GB4997@neu.nirvana> On Thu, Jan 04, 2007 at 01:13:25PM -0600, Clark Williams wrote: > Axel Thimm wrote: > > On Thu, Jan 04, 2007 at 10:37:03AM -0600, Clark Williams wrote: > >> New mock will no longer use mock-helper. When it needs to do something > >> that requires root privileges, it will elevate it's privilege level to > >> root (using os.setreuid()), execute the command and then drop privileges > >> back to the normal user. > > > > But isn't this a security regression towards the previous model? > > Previously all elevation procedures were confined and well > > controlled. > > > > One of the first thing that the __init__() method for class Root does in > mock.py is to call self.drop() to lower the privilege level. Thereafter, > any command that new mock does as root is done via the do_elevated() > method of the Root class, and any time the actual python code needs root > access (e.g. the rpm library routines), it's bracketed by elevate() and > drop() calls. This makes it easy to audit how the commands are used and > in what context code is executed. I understand the mechanism, but what if a security issue elsewhere in mock allows one to inject code and elevate privildeges? Until now any rogue mock takeover would only be able to do what the confined C helper program would allow, now everything is possible. > The main reason we wanted to get rid of mock-helper is that it was > non-trivial C code and the thought was to limit the amount of work > that's done at the C level. Yeah, I realize that it's easy to write bad > code in Python too, but it's harder to inadvertently set up a buffer > overflow situation in Python than in C. But now you have several times more code that can lead to priviledge escalations compared to before - in fact it sounds like all of the python code including all used non-mock python modules could run setreuid or not? -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From williams at redhat.com Thu Jan 4 21:11:23 2007 From: williams at redhat.com (Clark Williams) Date: Thu, 04 Jan 2007 15:11:23 -0600 Subject: RFC: new mock: strategy, selinux, etc. In-Reply-To: <20070104200601.GB4997@neu.nirvana> References: <459D2D2F.6030107@redhat.com> <20070104183211.GA4997@neu.nirvana> <459D51D5.10202@redhat.com> <20070104200601.GB4997@neu.nirvana> Message-ID: <459D6D7B.3090804@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Axel Thimm wrote: > On Thu, Jan 04, 2007 at 01:13:25PM -0600, Clark Williams wrote: >> One of the first thing that the __init__() method for class Root does in >> mock.py is to call self.drop() to lower the privilege level. Thereafter, >> any command that new mock does as root is done via the do_elevated() >> method of the Root class, and any time the actual python code needs root >> access (e.g. the rpm library routines), it's bracketed by elevate() and >> drop() calls. This makes it easy to audit how the commands are used and >> in what context code is executed. > > I understand the mechanism, but what if a security issue elsewhere in > mock allows one to inject code and elevate privildeges? Until now any > rogue mock takeover would only be able to do what the confined C > helper program would allow, now everything is possible. > I'm trying to figure out how someone would inject code into mock and not already be root (which to me means Game Over). To successfully exploit something, an attacker must cause some code to be loaded that either: 1. runs between an elevate and a drop or 2. does it's own os.setreuid(0, ...) To do #2, they would have to gain control of one of the 15 the files in /usr/lib/python2.X/* that we import. I'm not sure how someone would be able to gain control of a running instance of mock and be able to insert code arbitrarily. Please don't misunderstand me, I'm not dismissing your concerns, but I don't really see how this is any less secure than what we had previously. To me it's just a matter of where we focus our efforts in making mock secure. >> The main reason we wanted to get rid of mock-helper is that it was >> non-trivial C code and the thought was to limit the amount of work >> that's done at the C level. Yeah, I realize that it's easy to write bad >> code in Python too, but it's harder to inadvertently set up a buffer >> overflow situation in Python than in C. > > But now you have several times more code that can lead to priviledge > escalations compared to before - in fact it sounds like all of the > python code including all used non-mock python modules could run > setreuid or not? It's the same amount of privilege escalations as before, just under the control of the python code. You might want to take a look at this list thread: http://www.redhat.com/archives/fedora-buildsys-list/2006-June/msg00018.html which is what prompted this change. Clark -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFFnW17Hyuj/+TTEp0RAtY/AJ4zC1IS20iQtOLlkav/DqlQGQg2mgCfQbkF AmfG3awGJcGdXzp1yOZQQEA= =DcHc -----END PGP SIGNATURE----- From Axel.Thimm at ATrpms.net Thu Jan 4 21:38:52 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Thu, 4 Jan 2007 22:38:52 +0100 Subject: RFC: new mock: strategy, selinux, etc. In-Reply-To: <459D6D7B.3090804@redhat.com> References: <459D2D2F.6030107@redhat.com> <20070104183211.GA4997@neu.nirvana> <459D51D5.10202@redhat.com> <20070104200601.GB4997@neu.nirvana> <459D6D7B.3090804@redhat.com> Message-ID: <20070104213852.GA8480@neu.nirvana> On Thu, Jan 04, 2007 at 03:11:23PM -0600, Clark Williams wrote: > Axel Thimm wrote: > > On Thu, Jan 04, 2007 at 01:13:25PM -0600, Clark Williams wrote: > >> One of the first thing that the __init__() method for class Root does in > >> mock.py is to call self.drop() to lower the privilege level. Thereafter, > >> any command that new mock does as root is done via the do_elevated() > >> method of the Root class, and any time the actual python code needs root > >> access (e.g. the rpm library routines), it's bracketed by elevate() and > >> drop() calls. This makes it easy to audit how the commands are used and > >> in what context code is executed. > > > > I understand the mechanism, but what if a security issue elsewhere in > > mock allows one to inject code and elevate privildeges? Until now any > > rogue mock takeover would only be able to do what the confined C > > helper program would allow, now everything is possible. > > > > I'm trying to figure out how someone would inject code into mock and not > already be root (which to me means Game Over). To successfully exploit > something, an attacker must cause some code to be loaded that either: > > 1. runs between an elevate and a drop > or > 2. does it's own os.setreuid(0, ...) > > To do #2, they would have to gain control of one of the 15 the files in > /usr/lib/python2.X/* that we import. I'm not sure how someone would be > able to gain control of a running instance of mock and be able to insert > code arbitrarily. Well, security is about not creating chances and about having several lines of defenses. We shouldn't argue that any breach is a total breach, so why bother. In this argumentation line, why bother dropping root privileges at all? (That's rhetorical - of course - just trying to make my point). The point is that you open the vulnerabilty to mock python code, any other python code called by mock, as well as python itself. I think it was easier to deal with the few lines of C code. > >> The main reason we wanted to get rid of mock-helper is that it was > >> non-trivial C code and the thought was to limit the amount of work > >> that's done at the C level. Yeah, I realize that it's easy to write bad > >> code in Python too, but it's harder to inadvertently set up a buffer > >> overflow situation in Python than in C. > > > > But now you have several times more code that can lead to priviledge > > escalations compared to before - in fact it sounds like all of the > > python code including all used non-mock python modules could run > > setreuid or not? > > It's the same amount of privilege escalations as before, just under the > control of the python code. The helper C setuid wrapper would allow only certain operations, i.e. any priviledge escalation is confined to the defined operations in this helper. This also reduces the amount of code to be reviewed wrt priviledge escalation to just this wrapper. Now you have all of the python code exposed to possible priviledge escalation issues. In a nutshell: you now carry much more unlimited root power throughout all of mock's invocation cycle in comparison to a confined set of priviledges that the helper was giving. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From yanmin_zhang at linux.intel.com Fri Jan 5 03:15:55 2007 From: yanmin_zhang at linux.intel.com (Zhang, Yanmin) Date: Fri, 05 Jan 2007 11:15:55 +0800 Subject: Failed to buildup new images on ia64 Message-ID: <1167966955.15989.202.camel@ymzhang> I installed Fedora Core 6 on my ia64 machine. Then, after getting the new rpms from the latest ia64 development tree, I tried to buildup new iso images by pungi. The buildup failed. Pls. see below log. The new development tree uses python 2.5, but my distribution on machine installs python 2.4. If I replace it with 2.5, lots of other tools will be erased. The iso buildup also needs python 2.5 and the latest anaconda and yum. In the other hand, it looks like only with the new iso image, I could install python 2.5. Is it a chicken-egg issue? Is there any walkaround to install the latest python 2.5/anaconda/yum? Yanmin *************************************************pungi log******************************* Downloading eclipse-pde-3.2.1-23.fc7.ia64.rpm Running buildinstall... /mnt/tmp2/soft/work_pungi/pungi/7.01/ia64/os/buildinstall.tree.8438 /mnt/tmp2/soft/work_pungi rpm2cpio: /mnt/tmp2/soft/work_pungi/pungi/7.01/ia64/os/Fedora/anaconda-runtime-[0-9]*: No such file or directory cpio: premature end of archive /mnt/tmp2/soft/work_pungi cp: cannot stat `/mnt/tmp2/soft/work_pungi/pungi/7.01/ia64/os/buildinstall.tree.8438/usr/lib/anaconda-runtime/./upd-instroot*': No such file or directory cp: cannot stat `/mnt/tmp2/soft/work_pungi/pungi/7.01/ia64/os/buildinstall.tree.8438/usr/lib/anaconda-runtime/./mk-images*': No such file or directory cp: cannot stat `/mnt/tmp2/soft/work_pungi/pungi/7.01/ia64/os/buildinstall.tree.8438/usr/lib/anaconda-runtime/./makestamp.py*': No such file or directory cp: cannot stat `/mnt/tmp2/soft/work_pungi/pungi/7.01/ia64/os/buildinstall.tree.8438/usr/lib/anaconda-runtime/./buildinstall*': No such file or directory Building images... /usr/lib/anaconda-runtime/buildinstall: line 134: /mnt/tmp2/soft/work_pungi/pungi/7.01/ia64/os/buildinstall.tree.8438/upd-instroot: No such file or directory Creating repository metadata... Making images... /usr/lib/anaconda-runtime/buildinstall: line 146: /mnt/tmp2/soft/work_pungi/pungi/7.01/ia64/os/buildinstall.tree.8438/mk-images: No such file or directory Writing .discinfo file /usr/lib/anaconda-runtime/buildinstall: line 149: /mnt/tmp2/soft/work_pungi/pungi/7.01/ia64/os/buildinstall.tree.8438/makestamp.py: No such file or directory /mnt/tmp2/soft/work_pungi/pungi/work/ia64/docs /mnt/tmp2/soft/work_pungi 126 blocks /mnt/tmp2/soft/work_pungi /mnt/tmp2/soft/work_pungi/pungi/work/ia64/docs /mnt/tmp2/soft/work_pungi 4766 blocks /mnt/tmp2/soft/work_pungi Copying release note file RPM-GPG-KEY Copying release note file RPM-GPG-KEY-beta Copying release note file RPM-GPG-KEY-fedora Copying release note file RPM-GPG-KEY-fedora-extras Copying release note file RPM-GPG-KEY-fedora-legacy Copying release note file RPM-GPG-KEY-fedora-rawhide Copying release note file RPM-GPG-KEY-fedora-test Copying release note file RPM-GPG-KEY-rawhide Copying release note file GPL Copying release note file eula.txt Copying release note file README-BURNING-ISOS-en_US.txt Copying release note file RELEASE-NOTES-en_US.html Copying release note file fedora.css Copying release note dir stylesheet-images Traceback (most recent call last): File "/usr/bin/pungi", line 164, in ? main() File "/usr/bin/pungi", line 100, in main mypungi.doSplittree() File "/usr/lib/python2.4/site-packages/pypungi/pungi.py", line 108, in doSplittree output = timber.main() File "/usr/lib/python2.4/site-packages/pypungi/splittree.py", line 393, in main self.createSplitDirs() File "/usr/lib/python2.4/site-packages/pypungi/splittree.py", line 236, in createSplitDirs self.createDiscInfo(i) File "/usr/lib/python2.4/site-packages/pypungi/splittree.py", line 141, in createDiscInfo raise RuntimeError, "CRITICAL ERROR : .discinfo doesn't exist in the unified tree, not splitting" RuntimeError: CRITICAL ERROR : .discinfo doesn't exist in the unified tree, not splitting From jkeating at redhat.com Fri Jan 5 03:23:31 2007 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 4 Jan 2007 22:23:31 -0500 Subject: Failed to buildup new images on ia64 In-Reply-To: <1167966955.15989.202.camel@ymzhang> References: <1167966955.15989.202.camel@ymzhang> Message-ID: <200701042223.35885.jkeating@redhat.com> On Thursday 04 January 2007 22:15, Zhang, Yanmin wrote: > I installed Fedora Core 6 on my ia64 machine. Then, after getting the new > rpms from the latest ia64 development tree, I tried to buildup new iso > images by pungi. The buildup failed. Pls. see below log. > > The new development tree uses python 2.5, but my distribution on machine > installs python 2.4. If I replace it with 2.5, lots of other tools will be > erased. The iso buildup also needs python 2.5 and the latest anaconda and > yum. In the other hand, it looks like only with the new iso image, I could > install python 2.5. Is it a chicken-egg issue? Is there any walkaround to > install the latest python 2.5/anaconda/yum? You may need to create a chroot that is populated with the rawhide packages in order to run pungi there. I haven't done much pungi work on rawhide lately so I can't say of it is supposed to work or not. I was about to create the FC-6 branch of pungi and continue development in tip for rawhide/F7. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From williams at redhat.com Fri Jan 5 16:52:04 2007 From: williams at redhat.com (Clark Williams) Date: Fri, 05 Jan 2007 10:52:04 -0600 Subject: RFC: new mock: strategy, selinux, etc. In-Reply-To: <20070104213852.GA8480@neu.nirvana> References: <459D2D2F.6030107@redhat.com> <20070104183211.GA4997@neu.nirvana> <459D51D5.10202@redhat.com> <20070104200601.GB4997@neu.nirvana> <459D6D7B.3090804@redhat.com> <20070104213852.GA8480@neu.nirvana> Message-ID: <459E8234.9060403@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Axel Thimm wrote: > In a nutshell: you now carry much more unlimited root power throughout > all of mock's invocation cycle in comparison to a confined set of > priviledges that the helper was giving. Good point. I still think it's easier to audit python code than C code, but you're talking 500 lines of C versus 1000 lines of python. So, I may just reconsider this change. One of the reasons I liked moving to a setuid/setgid launcher was that we could move the process into the mock group and fix a bunch of chroot sharing problems with appropriate group permissions. Oh, and we actually kick off the python process in a separate namespace, which means we won't dirty up the mount table if for some reason we exit unexpectedly. If we just made the launcher setgid:mock and kept mock-helper for rootiness things, would that still trigger your security alarms? Hmmm, now that I think about it, we probably have to be root to create a new namespace, so the launcher might have to stay setuid:root and drop privileges before exec'ing python. Thoughts? Clark -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFFnoI0Hyuj/+TTEp0RAgs+AJ4wD3jbqZsb425aUEZ0O91phHWFygCeI+hQ 2V64J/BN6VINwdJSdFFfLDU= =vqnq -----END PGP SIGNATURE----- From Axel.Thimm at ATrpms.net Fri Jan 5 17:46:03 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Fri, 5 Jan 2007 18:46:03 +0100 Subject: RFC: new mock: strategy, selinux, etc. In-Reply-To: <459E8234.9060403@redhat.com> References: <459D2D2F.6030107@redhat.com> <20070104183211.GA4997@neu.nirvana> <459D51D5.10202@redhat.com> <20070104200601.GB4997@neu.nirvana> <459D6D7B.3090804@redhat.com> <20070104213852.GA8480@neu.nirvana> <459E8234.9060403@redhat.com> Message-ID: <20070105174603.GE14050@neu.nirvana> On Fri, Jan 05, 2007 at 10:52:04AM -0600, Clark Williams wrote: > Axel Thimm wrote: > > In a nutshell: you now carry much more unlimited root power throughout > > all of mock's invocation cycle in comparison to a confined set of > > priviledges that the helper was giving. > > Good point. I still think it's easier to audit python code than C code, > but you're talking 500 lines of C versus 1000 lines of python. So, I may > just reconsider this change. > > One of the reasons I liked moving to a setuid/setgid launcher was that > we could move the process into the mock group and fix a bunch of chroot > sharing problems with appropriate group permissions. Oh, and we actually > kick off the python process in a separate namespace, which means we > won't dirty up the mount table if for some reason we exit unexpectedly. > > If we just made the launcher setgid:mock and kept mock-helper for > rootiness things, would that still trigger your security alarms? Hmmm, > now that I think about it, we probably have to be root to create a new > namespace, so the launcher might have to stay setuid:root and drop > privileges before exec'ing python. > > Thoughts? How about a very radical approach: Removing the neccessity to have root priviledges at the first place anywhere. The benefits are clear security-wise, and you get the added bonus that you can have people install mock under their $HOME w/o being root on these system (imagine students working on campus/lab PCs). One could even create a Fedora SDK that runs on non-rpm Linux platforms - mock infiltrates everything ;) The question is whether that is technically possible - for what I use at ATrpms, an ancient bunch of shell scripts being the equivalent of mock, I use fakechroot/fakeroot to maintain chroots as a simple user. I think that will work with eliminating the need for the chroot part in the mock helper as well. If we check the remaining parts in mock requiring root priviledges (perhaps just for mounting?) perhaps we can eliminate these, too, and end up with a pure non-root working mock. I submitted fakeroot/fakechroot shortly before 2006 phased out, once they are through one can start playing with them (I think fakechroot is there, still waiting for fakeroot+dependency reviews to complete). BTW the Debian/Ubuntu build systems make extensive use of fakeroot/fakechroot for exactly the same scenarios. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From williams at redhat.com Fri Jan 5 19:04:20 2007 From: williams at redhat.com (Clark Williams) Date: Fri, 05 Jan 2007 13:04:20 -0600 Subject: RFC: new mock: strategy, selinux, etc. In-Reply-To: <20070105174603.GE14050@neu.nirvana> References: <459D2D2F.6030107@redhat.com> <20070104183211.GA4997@neu.nirvana> <459D51D5.10202@redhat.com> <20070104200601.GB4997@neu.nirvana> <459D6D7B.3090804@redhat.com> <20070104213852.GA8480@neu.nirvana> <459E8234.9060403@redhat.com> <20070105174603.GE14050@neu.nirvana> Message-ID: <459EA134.20803@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Axel Thimm wrote: > On Fri, Jan 05, 2007 at 10:52:04AM -0600, Clark Williams wrote: >> Axel Thimm wrote: >>> In a nutshell: you now carry much more unlimited root power throughout >>> all of mock's invocation cycle in comparison to a confined set of >>> priviledges that the helper was giving. >> Good point. I still think it's easier to audit python code than C code, >> but you're talking 500 lines of C versus 1000 lines of python. So, I may >> just reconsider this change. >> >> One of the reasons I liked moving to a setuid/setgid launcher was that >> we could move the process into the mock group and fix a bunch of chroot >> sharing problems with appropriate group permissions. Oh, and we actually >> kick off the python process in a separate namespace, which means we >> won't dirty up the mount table if for some reason we exit unexpectedly. >> >> If we just made the launcher setgid:mock and kept mock-helper for >> rootiness things, would that still trigger your security alarms? Hmmm, >> now that I think about it, we probably have to be root to create a new >> namespace, so the launcher might have to stay setuid:root and drop >> privileges before exec'ing python. >> >> Thoughts? > > How about a very radical approach: Removing the neccessity to have > root priviledges at the first place anywhere. The benefits are clear > security-wise, and you get the added bonus that you can have people > install mock under their $HOME w/o being root on these system (imagine > students working on campus/lab PCs). One could even create a Fedora > SDK that runs on non-rpm Linux platforms - mock infiltrates everything > ;) > > The question is whether that is technically possible - for what I use > at ATrpms, an ancient bunch of shell scripts being the equivalent of > mock, I use fakechroot/fakeroot to maintain chroots as a simple > user. I think that will work with eliminating the need for the chroot > part in the mock helper as well. If we check the remaining parts in > mock requiring root priviledges (perhaps just for mounting?) perhaps > we can eliminate these, too, and end up with a pure non-root working > mock. > > I submitted fakeroot/fakechroot shortly before 2006 phased out, once > they are through one can start playing with them (I think fakechroot > is there, still waiting for fakeroot+dependency reviews to complete). > > BTW the Debian/Ubuntu build systems make extensive use of > fakeroot/fakechroot for exactly the same scenarios. > I've used fakeroot/fakechroot in the past, but ran into RPM problems (where RPM wanted to take a lock that required root). I'm not positive, but I think that particular RPM problem has been fixed. I'm not adverse to trying it in the long run, but I don't really want to try and put it in for the next release. I want to get three things working for the next release: 1. Simplified uid/gid scheme so that multiple users can work properly 2. Running in our own namespace. 3. Proper SELinux integration What I'd like for #1 is for the process to setgid:mock once the user has been verified. At that point every file created has gid mock and so there shouldn't be any ownership conflicts in chroots. As far as I can tell the only way to setgid group is to run from a setgid program, so that means the launcher. I've seen two ways we can do namespaces. The first is a couple of patches that modify mock-helper. The other is to do it in the launcher. I'd prefer the launcher since it's less code than the patches to mock-helper. If we keep the launcher *and* mock-helper, and have the launcher do a setreuid(getuid(), getuid()) before exec'ing python, I /think/ that means we lose the ability to switch back to root (the euid). I'll need to go dig into my copy of Advanced Programming in the Unix Environment and probably write a test case to be sure. So again I ask: if we modify the launcher to setgid:mock and to drop root privilege after it's created the new namespace and before it exec's python, keeping mock-helper for root access, will that satisfy your security concerns for now? If so, we can get the three above things in, push it to rawhide and then discuss moving to fakeroot/fakechroot. Clark -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFFnqE0Hyuj/+TTEp0RAqBAAKDfFdrUgnm2Bpf0kRQ/xnVZkLnHWwCgwx5w L8JqelaoriBUY+HDS6IusO8= =EOJa -----END PGP SIGNATURE----- From Axel.Thimm at ATrpms.net Fri Jan 5 19:41:27 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Fri, 5 Jan 2007 20:41:27 +0100 Subject: RFC: new mock: strategy, selinux, etc. In-Reply-To: <459EA134.20803@redhat.com> References: <459D2D2F.6030107@redhat.com> <20070104183211.GA4997@neu.nirvana> <459D51D5.10202@redhat.com> <20070104200601.GB4997@neu.nirvana> <459D6D7B.3090804@redhat.com> <20070104213852.GA8480@neu.nirvana> <459E8234.9060403@redhat.com> <20070105174603.GE14050@neu.nirvana> <459EA134.20803@redhat.com> Message-ID: <20070105194127.GH14050@neu.nirvana> On Fri, Jan 05, 2007 at 01:04:20PM -0600, Clark Williams wrote: > Axel Thimm wrote: > > On Fri, Jan 05, 2007 at 10:52:04AM -0600, Clark Williams wrote: > >> Axel Thimm wrote: > >>> In a nutshell: you now carry much more unlimited root power throughout > >>> all of mock's invocation cycle in comparison to a confined set of > >>> priviledges that the helper was giving. > >> Good point. I still think it's easier to audit python code than C code, > >> but you're talking 500 lines of C versus 1000 lines of python. So, I may > >> just reconsider this change. > > How about a very radical approach: Removing the neccessity to have > > root priviledges at the first place anywhere. [...] The question > > is whether that is technically possible [...] I use > > fakechroot/fakeroot to maintain chroots as a simple user. I think > > that will work with eliminating the need for the chroot part in > > the mock helper as well. If we check the remaining parts in mock > > requiring root priviledges (perhaps just for mounting?) perhaps we > > can eliminate these, too, and end up with a pure non-root working > > mock. > I'm not adverse to trying it in the long run, but I don't really want to > try and put it in for the next release. I want to get three things > working for the next release: Indeed, I wasn't suggesting this as a short-term maneuvering. > So again I ask: if we modify the launcher to setgid:mock and to drop > root privilege after it's created the new namespace and before it exec's > python, keeping mock-helper for root access, will that satisfy your > security concerns for now? Yes, in that scenario it seems like the max possible damage is done by mock-group priviledges (if the helper itself doesn't come up with any issues), and the mock group cannot damage the host other than with resource draining, e.g. no further priviledge escalation. > If so, we can get the three above things in, push it to rawhide and > then discuss moving to fakeroot/fakechroot. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jkeating at redhat.com Fri Jan 5 19:42:51 2007 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 5 Jan 2007 14:42:51 -0500 Subject: RFC: new mock: strategy, selinux, etc. In-Reply-To: <20070105174603.GE14050@neu.nirvana> References: <459D2D2F.6030107@redhat.com> <459E8234.9060403@redhat.com> <20070105174603.GE14050@neu.nirvana> Message-ID: <200701051442.51610.jkeating@redhat.com> On Friday 05 January 2007 12:46, Axel Thimm wrote: > The question is whether that is technically possible - for what I use > at ATrpms, an ancient bunch of shell scripts being the equivalent of > mock, I use fakechroot/fakeroot to maintain chroots as a simple > user. I think that will work with eliminating the need for the chroot > part in the mock helper as well. If we check the remaining parts in > mock requiring root priviledges (perhaps just for mounting?) perhaps > we can eliminate these, too, and end up with a pure non-root working > mock. Would one still be able to do things IN the chroot like create loopback images and write to them? I need mock to be able to compose trees, which requires these types of things. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From Axel.Thimm at ATrpms.net Fri Jan 5 21:05:16 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Fri, 5 Jan 2007 22:05:16 +0100 Subject: RFC: new mock: strategy, selinux, etc. In-Reply-To: <200701051442.51610.jkeating@redhat.com> References: <459D2D2F.6030107@redhat.com> <459E8234.9060403@redhat.com> <20070105174603.GE14050@neu.nirvana> <200701051442.51610.jkeating@redhat.com> Message-ID: <20070105210516.GI14050@neu.nirvana> On Fri, Jan 05, 2007 at 02:42:51PM -0500, Jesse Keating wrote: > On Friday 05 January 2007 12:46, Axel Thimm wrote: > > The question is whether that is technically possible - for what I use > > at ATrpms, an ancient bunch of shell scripts being the equivalent of > > mock, I use fakechroot/fakeroot to maintain chroots as a simple > > user. I think that will work with eliminating the need for the chroot > > part in the mock helper as well. If we check the remaining parts in > > mock requiring root priviledges (perhaps just for mounting?) perhaps > > we can eliminate these, too, and end up with a pure non-root working > > mock. > > Would one still be able to do things IN the chroot like create loopback images > and write to them? I need mock to be able to compose trees, which requires > these types of things. I don't know, I haven't had the need to do so in chroots, but I would think that not, since fakeroot/fakechroot only emulates some library calls accociated with file access/manipulation and chrooting, and mounting requires kernel cooperation (even for fuse). So, if the kernel does not allow user mounts, and that's the only way to write/manipulate images then most likely no. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From giallu at gmail.com Tue Jan 9 12:26:39 2007 From: giallu at gmail.com (Gianluca Sforna) Date: Tue, 9 Jan 2007 13:26:39 +0100 Subject: make tag weirdness Message-ID: Is it just me, or the "make tag" command behaved strangely in this case ? [giallu at hal9001 devel]$ make tag cvs tag -c mantis-1_0_6-2_fc7 ? clog ? mantis-1.0.6 ? mantis-1.0.6-1.fc7.src.rpm ? mantis-1.0.6-2.fc7.src.rpm cvs tag: mantis-httpd.conf is locally modified cvs [tag aborted]: correct the above errors first! make: *** [tag] Error 1 [giallu at hal9001 devel]$ mv mantis-httpd.conf mantis-httpd.conf.new [giallu at hal9001 devel]$ cvs update ? clog ? mantis-1.0.6 ? mantis-1.0.6-1.fc7.src.rpm ? mantis-1.0.6-2.fc7.src.rpm ? mantis-httpd.conf.new cvs update: Updating . cvs update: warning: mantis-httpd.conf was lost U mantis-httpd.conf [giallu at hal9001 devel]$ make tag build cvs tag -c mantis-1_0_6-2_fc7 ? clog ? mantis-1.0.6 ? mantis-1.0.6-1.fc7.src.rpm ? mantis-1.0.6-2.fc7.src.rpm ? mantis-httpd.conf.new ERROR: Tag mantis-1_0_6-2_fc7 has been already created. The following tags have been created so far mantis-1_0_0-0_1_a3_fc5:devel:ensc:1119711001 mantis-0_19_2-2_fc4:FC-4:ensc:1119711469 mantis-0_19_3-1_fc4:FC-4:ensc:1130434051 mantis-1_0_0-0_1_rc4_fc5:devel:ensc:1135352863 mantis-0_19_4-1_fc4:FC-4:ensc:1135352893 mantis-1_0_0-1_fc5:devel:ensc:1140260422 mantis-1_0_1-1_fc5:devel:ensc:1141846123 mantis-1_0_3-1_fc6:devel:ensc:1148279495 mantis-1_0_5-1_fc6:devel:giallu:1160481046 mantis-1_0_5-1_fc5:FC-5:giallu:1161039528 mantis-1_0_5-1_fc5:FC-5:giallu:1161039915 mantis-1_0_5-1_fc5_1:FC-5:giallu:1161076958 mantis-0_19_4-2_fc4:FC-4:giallu:1161388633 mantis-1_0_6-1_fc7:devel:giallu:1162505136 mantis-1_0_6-1_fc6:FC-6:giallu:1162506434 mantis-1_0_6-1_fc5:FC-5:giallu:1162506806 mantis-1_0_6-2_fc7:devel:giallu:1168344682 I mean, the tag is NOT there, since the pre tag check failed, but it seems that now "make tag" believes otherwise. What am I missing? From Axel.Thimm at ATrpms.net Tue Jan 9 12:57:52 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Tue, 9 Jan 2007 13:57:52 +0100 Subject: make tag weirdness In-Reply-To: References: Message-ID: <20070109125752.GD10884@neu.nirvana> On Tue, Jan 09, 2007 at 01:26:39PM +0100, Gianluca Sforna wrote: > Is it just me, or the "make tag" command behaved strangely in this case ? > > [giallu at hal9001 devel]$ make tag > cvs tag -c mantis-1_0_6-2_fc7 > ERROR: Tag mantis-1_0_6-2_fc7 has been already created. > The following tags have been created so far > mantis-1_0_6-2_fc7:devel:giallu:1168344682 > > I mean, the tag is NOT there, since the pre tag check failed, but it > seems that now "make tag" believes otherwise. I can see the tag, I trimmed all the others. > What am I missing? Just use cvs tag -Fc mantis-1_0_6-2_fc7 to retag the files to finish the failed tga operation. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From giallu at gmail.com Tue Jan 9 16:47:15 2007 From: giallu at gmail.com (Gianluca Sforna) Date: Tue, 9 Jan 2007 17:47:15 +0100 Subject: make tag weirdness In-Reply-To: <20070109125752.GD10884@neu.nirvana> References: <20070109125752.GD10884@neu.nirvana> Message-ID: On 1/9/07, Axel Thimm wrote: > > mantis-1_0_6-2_fc7:devel:giallu:1168344682 > > > > I mean, the tag is NOT there, since the pre tag check failed, but it > > seems that now "make tag" believes otherwise. > > I can see the tag, I trimmed all the others. Oh yes, I also saw that. But, AFAICT, that list come from somewhere _ELSE_ than CVS itself (not sure where w/o digging in the Makefile). If I use cvs log on any file in my -devel branch files, no one has that tag. That is why I thought it looks like something to report in BZ (or on the infrastructure ticket system) I am wondering whether I should try to ignore what I know about cvs (I use it at work so it's probably my usage pattern that is triggering the problem). > > > What am I missing? > > Just use cvs tag -Fc mantis-1_0_6-2_fc7 to retag the files to finish > the failed tga operation. Thanks. I am sure that will work From mikem at redhat.com Thu Jan 11 23:15:17 2007 From: mikem at redhat.com (Mike McLean) Date: Thu, 11 Jan 2007 18:15:17 -0500 Subject: RFC: new mock: strategy, selinux, etc. In-Reply-To: <20070104183211.GA4997@neu.nirvana> References: <459D2D2F.6030107@redhat.com> <20070104183211.GA4997@neu.nirvana> Message-ID: <45A6C505.6030104@redhat.com> Axel Thimm wrote: > But isn't this a security regression towards the previous model? > Previously all elevation procedures were confined and well > controlled. I'm sorry for replying so late on this thread. I'd like to respond to some of the criticisms of the new model and explain some of the reasons I had for suggesting it. The mock-helper model is flawed because mock-helper does not have enough context to make informed security decisions. Any user in the mock group can run mock-helper directly and get it to perform any action that it would allow mock to do. While these actions are limited, they are not so limited that you can't do anything dangerous. In order to give mock-helper enough context to really know what it should allow, you would have to move large portions of the logic from mock.py to mock-helper, which would negate all the arguments about the size and complexity of the privileged code (note that mock-helper already accounts for about 30% of the lines of code). The current mock-helper security is swiss cheese anyway. A user in the mock group can become root inside the chroot with a simple mock or mock-helper command. As root, it is possible to escape from the chroot. Game Over. Suppose that we were to modify mock.py so that the shell and chroot commands run as a non-root user. Unfortunately mock-helper would still have to allow chroot as root, since mock.py needs this functionality itself. Users would still be able to run mock-helper directly. Even if we were able to plug that hole, the user would still be able to use mock-helper to install a suid binary into a chroot and then simply execute it. With the new model, we can at least address aspects of this because users in the mock group cannot access arbitrary mock-helper features. They can only take the actions that mock offers through the command line. Mock has all the context it needs to make such decisions. It knows what it should be doing. If we don't allow users to point to arbitrary mock configs, they will not be able to install arbitrary suid code in the chroots. If we don't allow users to chroot as root, they won't be able to get around it by calling mock-helper. > I understand the mechanism, but what if a security issue elsewhere in > mock allows one to inject code and elevate privildeges? Until now any > rogue mock takeover would only be able to do what the confined C > helper program would allow, now everything is possible. I'm not sure what type of exploit you're worried about here. As a python app, mock should be very resistant to buffer overflow exploits. Furthermore I'm not sure what interface the exploit would come through .. the command line? Clark's plan for dropping privilege and only elevating for key operations is a good one and will provide some protection against coding errors doing too much damage. I don't mean to say that the new model will be perfect. I think we will always need to caution admins to only add trusted users to the mock group. However, I think mock will be at least as secure as before and much more maintainable. From Axel.Thimm at ATrpms.net Fri Jan 12 13:48:37 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Fri, 12 Jan 2007 14:48:37 +0100 Subject: RFC: new mock: strategy, selinux, etc. In-Reply-To: <45A6C505.6030104@redhat.com> References: <459D2D2F.6030107@redhat.com> <20070104183211.GA4997@neu.nirvana> <45A6C505.6030104@redhat.com> Message-ID: <20070112134837.GH2988@neu.nirvana> On Thu, Jan 11, 2007 at 06:15:17PM -0500, Mike McLean wrote: > >I understand the mechanism, but what if a security issue elsewhere in > >mock allows one to inject code and elevate privildeges? Until now any > >rogue mock takeover would only be able to do what the confined C > >helper program would allow, now everything is possible. > > I'm not sure what type of exploit you're worried about here. As a python > app, mock should be very resistant to buffer overflow exploits. Check out for example CVE-2006-1542 and CVE-2006-4980. > Furthermore I'm not sure what interface the exploit would come through > .. the command line? Anything that mock takes as an input from command line to submitted srpms/spec files. One of the cve's was triggered by specially crafted UTF-32, next exploit could be with UTF-8 found in specfiles. If you run with possible root priviledge elevation capabilities all the time anything mock calls directly or indirectly becomes vulnerable, be it cpython itself or a python module used by mock. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From mikem at redhat.com Fri Jan 12 22:43:18 2007 From: mikem at redhat.com (Mike McLean) Date: Fri, 12 Jan 2007 17:43:18 -0500 Subject: RFC: new mock: strategy, selinux, etc. In-Reply-To: <20070112134837.GH2988@neu.nirvana> References: <459D2D2F.6030107@redhat.com> <20070104183211.GA4997@neu.nirvana> <45A6C505.6030104@redhat.com> <20070112134837.GH2988@neu.nirvana> Message-ID: <45A80F06.7090204@redhat.com> Axel Thimm wrote: > Check out for example CVE-2006-1542 and CVE-2006-4980. The first points out that CWD is a possible malicious input. If we treat that data as untrusted, then there are ways we could address such a python bug. For the second, there are patches for python that address it, and it appears the major vendors took notice.. But of course, your point was not so much these particular issues as it was to demonstrate that python has suffered buffer overflows. The fact is that mock's basic model requires that python code be executed as root. Even if mock itself were written entirely in C (not that I'm suggesting this), we must run /yum/ as root. To get around that, you'd have to either not use yum or use a substantially different yum, both of which are really far from where we are now. To me, such an approach would be a new project altogether. Exploits in the python interpreter are going to affect much more than mock. There are plenty of people out there using python in ways (as root or not) where exploits matter. As such, I think it is reasonable to expect that significant python exploits will be dealt with in a reasonable time frame by vendors. Also, a CVE search shows very few exploits that come from the python interpreter itself. In fact, you pretty much listed them all. Most of the rest come from the code written in python. This is something we can control at least. > Anything that mock takes as an input from command line to submitted > srpms/spec files. One of the cve's was triggered by specially crafted > UTF-32, next exploit could be with UTF-8 found in specfiles. If you > run with possible root priviledge elevation capabilities all the time > anything mock calls directly or indirectly becomes vulnerable, be it > cpython itself or a python module used by mock. Such a vulnerability could just as well affect yum, which mock has to run as root. Given to relative code sizes and install bases, I would expect it is much more likely that yum would be the target of this sort of exploit, and there's not much we can do about that (without a massive change in direction). So much of what mock does needs to be done as root that the mock-helper model creates a significant hurdle in clean design. The exec interface is slow and not very expressive. Also note the flaws I pointed out in my previous post. If the group is really worried about these sorts of exploits, then I think we can work on accomplishing stronger privilege separation within the python code (I have some ideas on this that I can talk about later if folks are interested). I do not think that mock-helper is the right answer. Getting rid of it is a good first step. From moe at blagblagblag.org Sat Jan 13 04:16:31 2007 From: moe at blagblagblag.org (jeff) Date: Sat, 13 Jan 2007 01:16:31 -0300 Subject: pungi on ia64 machine In-Reply-To: <1165545774.15989.86.camel@ymzhang> References: <1164964635.15989.12.camel@ymzhang> <200612061120.29243.jkeating@redhat.com> <1165461236.15989.72.camel@ymzhang> <200612071028.29426.jkeating@redhat.com> <1165545774.15989.86.camel@ymzhang> Message-ID: <45A85D1F.7030109@blagblagblag.org> Zhang, Yanmin wrote: > On Thu, 2006-12-07 at 10:28 -0500, Jesse Keating wrote: >> On Wednesday 06 December 2006 22:13, Zhang, Yanmin wrote: >>> /root/install.log showed anaconda didn't follow the sequence produced by >>> pkgorder to install rpms. I checked os-disc1/repodata/primary.xml.gz and >>> the rpm sequence was exatcly the same sequence of pkgorder. >> Hrm, this is starting to sound like an anaconda problem. I'd bring this >> thread up on an anconda user's list, or maybe fedora-devel list. > Thanks for helping push it! Looks like this: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=206211 -Jeff From yanmin_zhang at linux.intel.com Mon Jan 15 05:28:31 2007 From: yanmin_zhang at linux.intel.com (Zhang, Yanmin) Date: Mon, 15 Jan 2007 13:28:31 +0800 Subject: pungi on ia64 machine In-Reply-To: <45A85D1F.7030109@blagblagblag.org> References: <1164964635.15989.12.camel@ymzhang> <200612061120.29243.jkeating@redhat.com> <1165461236.15989.72.camel@ymzhang> <200612071028.29426.jkeating@redhat.com> <1165545774.15989.86.camel@ymzhang> <45A85D1F.7030109@blagblagblag.org> Message-ID: <1168838911.15989.248.camel@ymzhang> On Sat, 2007-01-13 at 01:16 -0300, jeff wrote: > Zhang, Yanmin wrote: > > On Thu, 2006-12-07 at 10:28 -0500, Jesse Keating wrote: > >> On Wednesday 06 December 2006 22:13, Zhang, Yanmin wrote: > >>> /root/install.log showed anaconda didn't follow the sequence produced by > >>> pkgorder to install rpms. I checked os-disc1/repodata/primary.xml.gz and > >>> the rpm sequence was exatcly the same sequence of pkgorder. > >> Hrm, this is starting to sound like an anaconda problem. I'd bring this > >> thread up on an anconda user's list, or maybe fedora-devel list. > > Thanks for helping push it! > > Looks like this: > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=206211 > Yes. I reported it at https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=219449. Now it has other issues. I am debugging. Yanmin From jeroen.janssen at gmail.com Sat Jan 20 08:22:12 2007 From: jeroen.janssen at gmail.com (Jeroen Janssen) Date: Sat, 20 Jan 2007 09:22:12 +0100 Subject: disc0 & pungi 0.1.2-2? Message-ID: Hello, Yesterday I installed a fresh FC6 machine, upgraded to the latest software (incl pungi 0.1.2-2), mirrored Fedora Core 6, Updates and Extras locally and performed a pungi run. The result failed with the following messages: du: cannot access `/files/pungi/srv/6.89/i386/os-disc0': No such file or directory Traceback (most recent call last): File "/usr/bin/pungi", line 164, in ? main() File "/usr/bin/pungi", line 100, in main mypungi.doSplittree() File "/usr/lib/python2.4/site-packages/pypungi/pungi.py", line 108, in doSplittree output = timber.main() File "/usr/lib/python2.4/site-packages/pypungi/splittree.py", line 394, in main self.splitRPMS() File "/usr/lib/python2.4/site-packages/pypungi/splittree.py", line 301, in splitRPMS curused = self.getSize("%s-disc%s" % (self.dist_dir, disc), blocksize=1) File "/usr/lib/python2.4/site-packages/pypungi/splittree.py", line 113, in getSize thesize = long(string.split(thesize)[0]) IndexError: list index out of range I'm on a i386 system building a i386 dvd. I used all the pungi config files 'as-is' from /etc/pungi (pungi.conf, yum.conf.i386, comps-fc6.xml). The only thing I changed was the location of the repositories (which are local). I thought this bug was already fixed in recent pungi. Best regards, Jeroen Janssen From jkeating at redhat.com Sat Jan 20 13:28:36 2007 From: jkeating at redhat.com (Jesse Keating) Date: Sat, 20 Jan 2007 08:28:36 -0500 Subject: disc0 & pungi 0.1.2-2? In-Reply-To: References: Message-ID: <200701200828.36964.jkeating@redhat.com> On Saturday 20 January 2007 03:22, Jeroen Janssen wrote: > I'm on a i386 system building a i386 dvd. > > I used all the pungi config files 'as-is' from /etc/pungi (pungi.conf, > yum.conf.i386, comps-fc6.xml). The only thing I changed was the > location of the repositories (which are local). > > I thought this bug was already fixed in recent pungi. pungi.conf is supposed to reference comps.xml I thought, not comps-fc6.xml. The problem you're seeing is that you've asked for 1 CD, but gave it 5~6 (depends on arch) CDs worth of packages (comps-fc6.xml), and anaconda doesn't like that so much. Change discs from 1 to 5 and try again. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jeroen.janssen at gmail.com Mon Jan 22 08:00:15 2007 From: jeroen.janssen at gmail.com (Jeroen Janssen) Date: Mon, 22 Jan 2007 09:00:15 +0100 Subject: pungi & nrofdiscs? Message-ID: Hi, I just was wondering about the discs option in pungi. Wouldn't it make more sense to just specify the size of disc(s)? I mean, specifying the nr of discs implies that you know beforehand the total discsize needed. What if I specify discs=5 and somehow the needed discspace exceeds 5 discs? If we just could specify the size of the discs, that means you automaticly end up with the amount of CDs needed for everything you want. Anyway, this way if you want to generate a DVD you just specify discsize to be of a DVD, or if you want multiple DVDs (think about CORE + EXTRAS) that's also solved aswell then. The only 'downside' is that you probably need multiple runs of pungi if you want to generate both DVD and CDs. Any other thoughts on this? Best regards, Jeroen Janssen From jkeating at redhat.com Mon Jan 22 13:17:25 2007 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 22 Jan 2007 08:17:25 -0500 Subject: pungi & nrofdiscs? In-Reply-To: References: Message-ID: <200701220817.30514.jkeating@redhat.com> On Monday 22 January 2007 03:00, Jeroen Janssen wrote: > I just was wondering about the discs option in pungi. > > Wouldn't it make more sense to just specify the size of disc(s)? > > I mean, specifying the nr of discs implies that you know beforehand > the total discsize needed. What if I specify discs=5 and somehow the > needed discspace exceeds 5 discs? > > If we just could specify the size of the discs, that means you > automaticly end up with the amount of CDs needed for everything you > want. > > Anyway, this way if you want to generate a DVD you just specify > discsize to be of a DVD, or if you want multiple DVDs (think about > CORE + EXTRAS) that's also solved aswell then. > > The only 'downside' is that you probably need multiple runs of pungi > if you want to generate both DVD and CDs. > > Any other thoughts on this? The problem is that anaconda-runtime is what splits the content across the CDs. It doesn't have the ability to look at the size and divide evenly. The roadmap is to move the splitting and package order logic out of anaconda-runtime and into createrepo itself, so that createrepo can split evenly across, splittree would just follow the manifest laid out by createrepo to put the packages in the right place. Neither of these things fall under the pungi project, pungi just makes use of these tools to get the compose created. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jeroen.janssen at gmail.com Tue Jan 23 14:21:34 2007 From: jeroen.janssen at gmail.com (Jeroen Janssen) Date: Tue, 23 Jan 2007 15:21:34 +0100 Subject: via-rhine problems with FC6 respins containing 2.6.19 kernel? Message-ID: Hi, I was wondering if anyone has made a FC6 respin yet that contains the 2.6.19 kernel (the one that was recently released in FC6-updates). I'm having some problems with networking on a via epia board, which claims that the network on eth0 (using via-rhine) is down, but if I boot from an original FC6 CD (containing the 2.6.18 kernel), networking detection & dhcp works without any problems. I'll try to rebuild the FC6 respin without the 2.6.19 kernel and see if that solves my problem. Best regards, Jeroen Janssen From giallu at gmail.com Wed Jan 24 07:39:40 2007 From: giallu at gmail.com (Gianluca Sforna) Date: Wed, 24 Jan 2007 08:39:40 +0100 Subject: via-rhine problems with FC6 respins containing 2.6.19 kernel? In-Reply-To: References: Message-ID: On 1/23/07, Jeroen Janssen wrote: > I was wondering if anyone has made a FC6 respin yet that contains the > 2.6.19 kernel (the one that was recently released in FC6-updates). > > I'm having some problems with networking on a via epia board, which > claims that the network on eth0 (using via-rhine) is down, but if I > boot from an original FC6 CD (containing the 2.6.18 kernel), > networking detection & dhcp works without any problems. > > I'll try to rebuild the FC6 respin without the 2.6.19 kernel and see > if that solves my problem. > I wonder if respins/LiveCDs should include the last couple of released kernels to help on this kind of things... From jeroen.janssen at gmail.com Wed Jan 24 16:23:57 2007 From: jeroen.janssen at gmail.com (Jeroen Janssen) Date: Wed, 24 Jan 2007 17:23:57 +0100 Subject: openSUSE build service? Message-ID: Hi, I just noticed the official release of the openSUSE build service ( http://lwn.net/Articles/218886/ ). I haven't had a detailed look at it, but they provide both client(worker) and server rpm packages for Fedora Core 6. If I understand correctly, this means one can setup a FC6 based build system for building RPM packages for FC6 (maybe one could build the entire fedora core/extras repositories out of the box with this system?). I assume (but I do not have any detailed knowledge of this), that it's possible to build FC6 based RPMs, without modifying the spec files for this build service. They seem to have some mechanism that allows for cross-distribution RPMs, but I'm not sure if that is a requirement for being able to build (I sure hope not, since that would make it less useable). Is there any updated info on the brew/plague status? Best regards, Jeroen Janssen From mythtv.bohmer at gmail.com Fri Jan 26 20:50:13 2007 From: mythtv.bohmer at gmail.com (Remy Bohmer) Date: Fri, 26 Jan 2007 21:50:13 +0100 Subject: using pungi for custom installations Message-ID: Hello Jesse, I am thankful for that you have built pungi, but while using it I ran into the following questions. I hope you can answer them: I am using pungi to be able to build a custom distribution based on FC6 for an embedded target. Currently I have achieved to build a minimal CD-image of about 400 MB by specifying a smaller comps.xml file. But the size is still too big as there is a lot of unneeded stuff in it... 1. The generated ISO image contains xorg RPM packages which I do not need. I want a text-only installation method (by using the serial console option of Anaconda), as we do not have a VGA display on our target. Is there an easy way to get rid of these xorg packages? 2. Currently only 1 ISO image is built with all packages in it. What I actually want is that 2 ISO's are being built: the 1st ISO containing the core installation (which almost never changes) with all boot and Anaconda stuff on it, and a 2nd ISO containing the frequently changing applications.(a predefined set of RPMs) Is there a way to split up the list of RPM's in a predefined way (not related to disc size) and that Anaconda during installation asks for the 2nd disc? 3. Is there a easy way to get my own build kickstart file on the 1st ISO through the pungi framework, without the need of rebuilding the ISO files myself. (And to modify the isolinux configuration file to default load this kickstart file?) I hope you can help me by answering these questions... Kind Regards, Remy Bohmer -------------- next part -------------- An HTML attachment was scrubbed... URL: From jkeating at redhat.com Fri Jan 26 21:02:36 2007 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 26 Jan 2007 16:02:36 -0500 Subject: using pungi for custom installations In-Reply-To: References: Message-ID: <200701261602.37018.jkeating@redhat.com> On Friday 26 January 2007 15:50, Remy Bohmer wrote: > 1. The generated ISO image contains xorg RPM packages which I do not need. > I want a text-only installation method (by using the serial console option > of Anaconda), as we do not have a VGA display on our target. Is there an > easy way to get rid of these xorg packages? So right now, those are getting pulled in so that anaconda can build its images for the install. If you don't list say anaconda-runtime and anaconda in your comps, it may still work, and you'll just only be able to do text installs. Right now I don't have separated a list of packages anaconda needs to create its images vs a list of packages in the compose. > 2. Currently only 1 ISO image is built with all packages in it. What I > actually want is that 2 ISO's are being built: the 1st ISO containing the > core installation (which almost never changes) with all boot and Anaconda > stuff on it, and a 2nd ISO containing the frequently changing > applications.(a predefined set of RPMs) > Is there a way to split up the list of RPM's in a predefined way (not > related to disc size) and that Anaconda during installation asks for the > 2nd disc? That is all done by anaconda-runtime's splittree.py, and what you're trying to do doesn't sound all that accomplishable unfortunately. > 3. Is there a easy way to get my own build kickstart file on the 1st ISO > through the pungi framework, without the need of rebuilding the ISO files > myself. (And to modify the isolinux configuration file to default load this > kickstart file?) > > I hope you can help me by answering these questions... There is a config option for releasenote files / packages. See /usr/bin/pungi You can treat a kickstart file as a release note file, and package it up into a package you include in your spin. As for altering isolinux, that you'll have to figure out on your own. However if you boot with "linux ks" it'll hunt for a ks.cfg on the root of the CD you are booting with. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jeroen.janssen at gmail.com Fri Jan 26 22:10:38 2007 From: jeroen.janssen at gmail.com (Jeroen Janssen) Date: Fri, 26 Jan 2007 23:10:38 +0100 Subject: using pungi for custom installations In-Reply-To: <200701261602.37018.jkeating@redhat.com> References: <200701261602.37018.jkeating@redhat.com> Message-ID: On 1/26/07, Jesse Keating wrote: > So right now, those are getting pulled in so that anaconda can build its > images for the install. If you don't list say anaconda-runtime and anaconda > in your comps, it may still work, and you'll just only be able to do text > installs. Right now I don't have separated a list of packages anaconda needs > to create its images vs a list of packages in the compose. Currently anaconda builds both a stage2.img (graphical) and a minstg2.img (text) image. As a first step would it possible to have anaconda just build the minstg2.img (textonly) image depending on a commandline option? I'm wondering what exactly pulls in the xorg packages. Is this something gets pulled in because anaconda-runtime has dependencies to xorg? So that would mean in order to build an iso without xorg would need a custom anaconda-runtime package with different dependencies? note: upd-instroot contains a list of all the needed packages that are used during image creation. > > 2. Currently only 1 ISO image is built with all packages in it. What I > > actually want is that 2 ISO's are being built: the 1st ISO containing the > > core installation (which almost never changes) with all boot and Anaconda > > stuff on it, and a 2nd ISO containing the frequently changing > > applications.(a predefined set of RPMs) > > Is there a way to split up the list of RPM's in a predefined way (not > > related to disc size) and that Anaconda during installation asks for the > > 2nd disc? > > That is all done by anaconda-runtime's splittree.py, and what you're trying to > do doesn't sound all that accomplishable unfortunately. What exactly makes anaconda 'ask' for the 2nd disc? Would it be possible to just generate a single CD with pungi and "manually" generate a 2nd "application" ISO with a repository on it that can be used during installation? Then you could alter the pungi generated iso to let anaconda know it's a 2disc installation. Best regards, Jeroen Janssen From jkeating at redhat.com Fri Jan 26 22:19:46 2007 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 26 Jan 2007 17:19:46 -0500 Subject: using pungi for custom installations In-Reply-To: References: <200701261602.37018.jkeating@redhat.com> Message-ID: <200701261719.49646.jkeating@redhat.com> On Friday 26 January 2007 17:10, Jeroen Janssen wrote: > What exactly makes anaconda 'ask' for the 2nd disc? The repodata on the first cd has media:// numbers. If you checkbox a package that exists on the second media, anaconda will ask for it. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jeroen.janssen at gmail.com Fri Jan 26 22:33:05 2007 From: jeroen.janssen at gmail.com (Jeroen Janssen) Date: Fri, 26 Jan 2007 23:33:05 +0100 Subject: using pungi for custom installations In-Reply-To: <200701261719.49646.jkeating@redhat.com> References: <200701261602.37018.jkeating@redhat.com> <200701261719.49646.jkeating@redhat.com> Message-ID: On 1/26/07, Jesse Keating wrote: > On Friday 26 January 2007 17:10, Jeroen Janssen wrote: > > What exactly makes anaconda 'ask' for the 2nd disc? > > The repodata on the first cd has media:// numbers. If you checkbox a package > that exists on the second media, anaconda will ask for it. Ok, so basically the following should work? * generate a single CD with pungi (containing only FC6 stuff) * extract the generated CD to /cd1/ * generate a 2nd tree with app RPMS in /cd2/ (who generates .discinfo?) * rerun createrepo on the tree with --split option resulting in new repodata being generated in CD1. * create new isos of cd1 and cd2 It's probably a bit of a 'hack' though :) Best regards, Jeroen Janssen From jkeating at redhat.com Fri Jan 26 22:39:45 2007 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 26 Jan 2007 17:39:45 -0500 Subject: using pungi for custom installations In-Reply-To: References: <200701261719.49646.jkeating@redhat.com> Message-ID: <200701261739.45332.jkeating@redhat.com> On Friday 26 January 2007 17:33, Jeroen Janssen wrote: > Ok, so basically the following should work? > * generate a single CD with pungi (containing only FC6 stuff) > * extract the generated CD to /cd1/ > * generate a 2nd tree with app RPMS in /cd2/ (who generates > .discinfo?) * rerun createrepo on the tree with --split option > resulting in new repodata being generated in CD1. > * create new isos of cd1 and cd2 > > It's probably a bit of a 'hack' though :) Alternatively, use a different splittree to split stuff how you want it during the compose, and let createrepo just happen. Easier than compose/alter/compose. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jeroen.janssen at gmail.com Sun Jan 28 10:12:12 2007 From: jeroen.janssen at gmail.com (Jeroen Janssen) Date: Sun, 28 Jan 2007 11:12:12 +0100 Subject: Mock "Could not find useradd in chroot, maybe the install failed?" Message-ID: Hi, I have been trying to build F7Test1 for a couple of days now, but I seem to be doing something wrong. Since I'm running a FC6 (latest updates) system, I need to run pungi within mock in order to generate the F7Test1 installation media. However, I can't seem to get mock to work, so I cannot build the installation media. As a test, I'm running the following: mock --debug -r fedora-6-i386-core init and the latest part of the output is: DEBUG: Executing /usr/sbin/mock-helper yum --installroot /var/lib/mock/fedora-6-i386-core/root update Could not find useradd in chroot, maybe the install failed? ending I get the same error when trying to setup a mock for fedora-devel. This is with mock 0.6.10-1.fc6, with the default mock configfiles. Anyone here having the same problem, or is it just me? Best regards, Jeroen Janssen From williams at redhat.com Mon Jan 29 17:04:33 2007 From: williams at redhat.com (Clark Williams) Date: Mon, 29 Jan 2007 11:04:33 -0600 Subject: Mock "Could not find useradd in chroot, maybe the install failed?" In-Reply-To: References: Message-ID: <45BE2921.2010208@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Jeroen Janssen wrote: > Hi, > > I have been trying to build F7Test1 for a couple of days now, but I > seem to be doing something wrong. Since I'm running a FC6 (latest > updates) system, I need to run pungi within mock in order to generate > the F7Test1 installation media. > > However, I can't seem to get mock to work, so I cannot build the > installation media. > > As a test, I'm running the following: > mock --debug -r fedora-6-i386-core init > > and the latest part of the output is: > > DEBUG: Executing /usr/sbin/mock-helper yum --installroot > /var/lib/mock/fedora-6-i386-core/root update > Could not find useradd in chroot, maybe the install failed? > ending > > I get the same error when trying to setup a mock for fedora-devel. > > This is with mock 0.6.10-1.fc6, with the default mock configfiles. > > Anyone here having the same problem, or is it just me? > > Best regards, > > Jeroen Janssen Well, I was going to say that it might not be in the path, since mock-helper doesn't inherit a path, but /usr/sbin is in that path and that's usually where useradd is found. After a failure, try running : mock -r fedora-6-i386-core --no-clean shell and poke around in the chroot. Is useradd actually there? Clark -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFFvikhHyuj/+TTEp0RArJ0AJ9VwwFsg2bG8VpPnKvY0AtheJnrKwCffNEO +E8neXWDzYJbxu/JbpCC1pQ= =tPgs -----END PGP SIGNATURE----- From mythtv.bohmer at gmail.com Mon Jan 29 19:33:39 2007 From: mythtv.bohmer at gmail.com (Remy Bohmer) Date: Mon, 29 Jan 2007 20:33:39 +0100 Subject: missing binaries during installation from CD built with pungi Message-ID: Hello Jesse, I have discovered a new problem with building a CD image with pungi. I hope you have an idea what can be the cause: * During installation and executing the pre-scripts, the binary called 'basename' lacks in the environment.(Notice that my scripts and kickstart configuration work properly while doing a network installation with default FC6 boot.iso and diskboot.img, while doing network installations, basename is there...) * During partitioning the installer cannot find the binary '/usr/sbin/mkfs.xfs' * Somewhere during the build I got a message 'unable to stat busybox.anaconda'. Are these problems related? And what could cause the lack of these binaries? Any suggestions? Thanks in advance... Kind Regards, Remy Bohmer From jkeating at redhat.com Mon Jan 29 19:53:03 2007 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 29 Jan 2007 14:53:03 -0500 Subject: missing binaries during installation from CD built with pungi In-Reply-To: References: Message-ID: <200701291453.03278.jkeating@redhat.com> On Monday 29 January 2007 14:33, Remy Bohmer wrote: > Hello Jesse, > > I have discovered a new problem with building a CD image with pungi. I > hope you have an idea what can be the cause: > * During installation and executing the pre-scripts, the binary called > 'basename' lacks in the environment.(Notice that my scripts and > kickstart configuration work properly while doing a network > installation with default FC6 boot.iso and diskboot.img, while doing > network installations, basename is there...) > * During partitioning the installer cannot find the binary > '/usr/sbin/mkfs.xfs' * Somewhere during the build I got a message 'unable > to stat busybox.anaconda'. > > Are these problems related? And what could cause the lack of these > binaries? Any suggestions? > > Thanks in advance... Probably busybox-anaconda is missing from the comps or manifest (depending on if you're composing FC6 or devel). -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From stefmanos at gmail.com Tue Jan 30 06:37:00 2007 From: stefmanos at gmail.com (Stephanos Manos) Date: Tue, 30 Jan 2007 08:37:00 +0200 Subject: pungi error Message-ID: <1170139020.4164.11.camel@ghost.home-net> Hi First sorry if posting in the wrong list. Trying to respond to the QA call for test 1 i followed the instructions posted to build using pungi inside mock (i am currently ruuning FC6) using a locally mirrored repo. When the building process finished with the ok message i did a sha1sum check on the output with sha1sum -c SHA1SUM and all except the rescue cd fail. [root at ghost iso]# cat SHA1SUM 0cb6c915cd932fb3d096a15110d746b1267295e8 FD-6.90-i386-disc1.iso e0c1b387eb0755726698e6da4e1a1bf5858fbd5a FD-6.90-i386-disc2.iso 2f2f18d366f62812746f9d779e7b4efa77c6fde6 FD-6.90-i386-disc3.iso 99d2733ed1ee1da6c0d78541b2672418d374fb63 FD-6.90-i386-DVD.iso c2c4434fbf976f7a8f4673903d5e74ea9e79e040 FD-6.90-i386-rescuecd.iso [root at ghost iso]# sha1sum *.iso 65e3ed52628e3f20cd0eb364f28e864f3afa445e FD-6.90-i386-disc1.iso dbf3fa3f6cd09025ae89c45ed760bd77c21973d5 FD-6.90-i386-disc2.iso 87da6d5d6a20c1f10ad82b9702952f2240054657 FD-6.90-i386-disc3.iso b66c7d8826aa52c1a3c5efab53c1f174cb230446 FD-6.90-i386-DVD.iso c2c4434fbf976f7a8f4673903d5e74ea9e79e040 FD-6.90-i386-rescuecd.iso inside mock Executing /usr/sbin/mock-helper chroot /var/lib/mock/fedora-development-i386-core/root /sbin/runuser - root -c "cd /srv/pungi/f7-test1/6.90/Desktop/i386/iso ; /usr/bin/sha1sum *.iso" b66c7d8826aa52c1a3c5efab53c1f174cb230446 FD-6.90-i386-DVD.iso 65e3ed52628e3f20cd0eb364f28e864f3afa445e FD-6.90-i386-disc1.iso dbf3fa3f6cd09025ae89c45ed760bd77c21973d5 FD-6.90-i386-disc2.iso 87da6d5d6a20c1f10ad82b9702952f2240054657 FD-6.90-i386-disc3.iso c2c4434fbf976f7a8f4673903d5e74ea9e79e040 FD-6.90-i386-rescuecd.iso regardless the error output when booting with the dvd disk and running the media check option it passes. due to time restrictions and missing a spare HD to install i haven't tested more thoroughly is it a known problem/regression of pungi or a problem on my side? should i open a BZ ticket? Stephanos Manos From jkeating at redhat.com Tue Jan 30 15:21:35 2007 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 30 Jan 2007 10:21:35 -0500 Subject: pungi error In-Reply-To: <1170139020.4164.11.camel@ghost.home-net> References: <1170139020.4164.11.camel@ghost.home-net> Message-ID: <200701301021.35407.jkeating@redhat.com> On Tuesday 30 January 2007 01:37, Stephanos Manos wrote: > is it a known problem/regression of pungi or a problem on my side? To be perfectly honest, I haven't actually verified that the sha1sums in the file actually match the isos. I just took it for granted, but perhaps I did something silly like insert the mediacheck checksum after I sha1summed the file. I'll look into this right now. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jkeating at redhat.com Tue Jan 30 15:41:33 2007 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 30 Jan 2007 10:41:33 -0500 Subject: pungi error In-Reply-To: <200701301021.35407.jkeating@redhat.com> References: <1170139020.4164.11.camel@ghost.home-net> <200701301021.35407.jkeating@redhat.com> Message-ID: <200701301041.34132.jkeating@redhat.com> On Tuesday 30 January 2007 10:21, Jesse Keating wrote: > To be perfectly honest, I haven't actually verified that the sha1sums in > the file actually match the isos. ?I just took it for granted, but perhaps > I did something silly like insert the mediacheck checksum after I > sha1summed the file. ?I'll look into this right now. Whoops, yep, I screwed that one up good. I did sha1sum at first, later added implantmd5, and forgot to implant _before_ calculating the sha1sum. I've just committed a fix for this to pungi hg. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From mythtv.bohmer at gmail.com Wed Jan 31 11:40:47 2007 From: mythtv.bohmer at gmail.com (Remy Bohmer) Date: Wed, 31 Jan 2007 12:40:47 +0100 Subject: pungi ignores a lot of RPMs when building CD image Message-ID: Hello all, I hope someone can help me on this one. Probably I am doing something wrong, but I cannot figure out what I do wrong: I am building a customised CD based on FC6 RPMs+custom RPMs. The problem I see is that the directory os/ contains all RPMS including all dependencies, but the directory os-disc1/ only contain a strange subset of the RPMs. I have 10 custom RPMs, but the os-disc1 directory contains only 31, and I expect a total of 330 RPMs. Notice that the entire RPM-collection in the os dir is about 340 MB, which properly fits on 1 CD. After the build only 1 iso is created of about 150 MB. So, calculating dependencies based on my comps.xml works well, but splitting the tree into CD's ignores a lot of RPMs. Does anyone here has an idea of what I might have forgotten to configure, or which error I make? Note: even the glibc rpms are not there in the CD-image... Therefor anaconda fails during installation (extraction phase of the RPMs), as it cannot find some localisation files. Kind Regards, Remy Bohmer From jkeating at redhat.com Wed Jan 31 13:11:45 2007 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 31 Jan 2007 08:11:45 -0500 Subject: pungi ignores a lot of RPMs when building CD image In-Reply-To: References: Message-ID: <200701310811.49663.jkeating@redhat.com> On Wednesday 31 January 2007 06:40, Remy Bohmer wrote: > Hello all, > > I hope someone can help me on this one. Probably I am doing something > wrong, but I cannot figure out what I do wrong: > > I am building a customised CD based on FC6 RPMs+custom RPMs. > > The problem I see is that the directory os/ contains all > RPMS including all dependencies, but the directory os-disc1/ > only contain a strange subset of the RPMs. I have 10 custom RPMs, but > the os-disc1 directory contains only 31, and I expect a total of 330 > RPMs. > Notice that the entire RPM-collection in the os dir is about 340 MB, > which properly fits on 1 CD. After the build only 1 iso is created of > about 150 MB. How many discs are you asking for in your config file? Also, what groups are they in within comps? splittree does ordering based on comps groups, could have something to do with this. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From mythtv.bohmer at gmail.com Wed Jan 31 13:42:12 2007 From: mythtv.bohmer at gmail.com (Remy Bohmer) Date: Wed, 31 Jan 2007 14:42:12 +0100 Subject: pungi ignores a lot of RPMs when building CD image In-Reply-To: <200701310811.49663.jkeating@redhat.com> References: <200701310811.49663.jkeating@redhat.com> Message-ID: Hello Jesse, In my config file there is only 1 disc. In my comps file there are 4 groups, namely pungi, Core (=copied from FC6 Comps), and 2 custom groups. See attached my configuration files. Kind Regards, Remy 2007/1/31, Jesse Keating : > On Wednesday 31 January 2007 06:40, Remy Bohmer wrote: > > Hello all, > > > > I hope someone can help me on this one. Probably I am doing something > > wrong, but I cannot figure out what I do wrong: > > > > I am building a customised CD based on FC6 RPMs+custom RPMs. > > > > The problem I see is that the directory os/ contains all > > RPMS including all dependencies, but the directory os-disc1/ > > only contain a strange subset of the RPMs. I have 10 custom RPMs, but > > the os-disc1 directory contains only 31, and I expect a total of 330 > > RPMs. > > Notice that the entire RPM-collection in the os dir is about 340 MB, > > which properly fits on 1 CD. After the build only 1 iso is created of > > about 150 MB. > > How many discs are you asking for in your config file? Also, what groups are > they in within comps? splittree does ordering based on comps groups, could > have something to do with this. > > -- > Jesse Keating > Release Engineer: Fedora > > -- > Fedora-buildsys-list mailing list > Fedora-buildsys-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-buildsys-list > > -------------- next part -------------- A non-text attachment was scrubbed... Name: comps.xml Type: text/xml Size: 10442 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: pungi.conf Type: application/octet-stream Size: 289 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: yum.conf Type: application/octet-stream Size: 896 bytes Desc: not available URL: From jkeating at redhat.com Wed Jan 31 15:20:58 2007 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 31 Jan 2007 10:20:58 -0500 Subject: pungi ignores a lot of RPMs when building CD image In-Reply-To: References: <200701310811.49663.jkeating@redhat.com> Message-ID: <200701311020.58794.jkeating@redhat.com> On Wednesday 31 January 2007 08:42, Remy Bohmer wrote: > Hello Jesse, > > In my config file there is only 1 disc. In my comps file there are 4 > groups, namely pungi, Core (=copied from FC6 Comps), and 2 custom > groups. See attached my configuration files. Just for snorts, name one of your groups "base". That and see what packageorder does on your tree. pypungi/pungi.py has the pkgorder command used. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From guillermo.gomez at gmail.com Wed Jan 31 15:47:45 2007 From: guillermo.gomez at gmail.com (=?UTF-8?B?Ikd1aWxsZXJtbyBHw7NtZXogUy4i?=) Date: Wed, 31 Jan 2007 11:47:45 -0400 Subject: Hi list Message-ID: <45C0BA21.30408@gmail.com> Hi, im new to this list and i would like to contribute with it. Where should i start ? kind regards -- Gomix Guillermo G?mez S. cms fedora-ve http://www.fedora-ve.org blog http://blog.gomix.org soporte fedora-ve en irc.freenode.net, canal fedora-ve lista email fedora-ve at googlegroups.com Key fingerprint = 3143 8BDB 48A2 3241 E62A B743 D177 CAD7 3205 A464 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: OpenPGP digital signature URL: From mythtv.bohmer at gmail.com Wed Jan 31 16:58:45 2007 From: mythtv.bohmer at gmail.com (Remy Bohmer) Date: Wed, 31 Jan 2007 17:58:45 +0100 Subject: pungi ignores a lot of RPMs when building CD image In-Reply-To: <200701311020.58794.jkeating@redhat.com> References: <200701310811.49663.jkeating@redhat.com> <200701311020.58794.jkeating@redhat.com> Message-ID: Hello Jesse, I named it Base, but unfortunately it makes no difference. Is it case sensitive? 'base' versus 'Base' ? What did you mean with the line: 'That and see what packageorder does on your tree. pypungi/pungi.py has the pkgorder command used.' ? Should I run some command and check its output? I rebuilt everything with pung, and checked its output for now... Do you have any other ideas? Kind Regards, Remy Bohmer 2007/1/31, Jesse Keating : > On Wednesday 31 January 2007 08:42, Remy Bohmer wrote: > > Hello Jesse, > > > > In my config file there is only 1 disc. In my comps file there are 4 > > groups, namely pungi, Core (=copied from FC6 Comps), and 2 custom > > groups. See attached my configuration files. > > Just for snorts, name one of your groups "base". That and see what > packageorder does on your tree. pypungi/pungi.py has the pkgorder command > used. > > -- > Jesse Keating > Release Engineer: Fedora > > -- > Fedora-buildsys-list mailing list > Fedora-buildsys-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-buildsys-list > > From jkeating at redhat.com Wed Jan 31 18:11:11 2007 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 31 Jan 2007 13:11:11 -0500 Subject: pungi ignores a lot of RPMs when building CD image In-Reply-To: References: <200701311020.58794.jkeating@redhat.com> Message-ID: <200701311311.11648.jkeating@redhat.com> On Wednesday 31 January 2007 11:58, Remy Bohmer wrote: > What did you mean with the line: 'That and see what packageorder does > on your tree. ?pypungi/pungi.py has the pkgorder command used.' ? > Should I run some command and check its output? > I rebuilt everything with pung, and checked its output for now... Use: /usr/lib/anaconda-runtime/pkgorder /path/to/your/os Fedora That will spit out a package order that is used by splittree to put your packages on various CDs. I'd be interested to see if all the packages in your compose make it. pkgorder is a python script, so you can use python debugger (pdb) to see whats going on. pkgorder is also part of anaconda-runtime, so any bugs found belong to the anaconda group, not pungi (: -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From mythtv.bohmer at gmail.com Wed Jan 31 19:47:08 2007 From: mythtv.bohmer at gmail.com (Remy Bohmer) Date: Wed, 31 Jan 2007 20:47:08 +0100 Subject: pungi ignores a lot of RPMs when building CD image In-Reply-To: <200701311311.11648.jkeating@redhat.com> References: <200701311020.58794.jkeating@redhat.com> <200701311311.11648.jkeating@redhat.com> Message-ID: Hello Jesse, Thanks for your excellent help on this, I will try this pkgorder suggestion immediately tomorrow morning... It is evening here in the Netherlands, and I do not have the CD-build stuff at home... BTW: Do you prefer contact through this mailinglist, or IRC ? Kind Regards, Remy Bohmer 2007/1/31, Jesse Keating : > On Wednesday 31 January 2007 11:58, Remy Bohmer wrote: > > What did you mean with the line: 'That and see what packageorder does > > on your tree. pypungi/pungi.py has the pkgorder command used.' ? > > Should I run some command and check its output? > > I rebuilt everything with pung, and checked its output for now... > > Use: > > /usr/lib/anaconda-runtime/pkgorder /path/to/your/os Fedora > > That will spit out a package order that is used by splittree to put your > packages on various CDs. I'd be interested to see if all the packages in > your compose make it. > > pkgorder is a python script, so you can use python debugger (pdb) to see whats > going on. > > pkgorder is also part of anaconda-runtime, so any bugs found belong to the > anaconda group, not pungi (: > > -- > Jesse Keating > Release Engineer: Fedora > > -- > Fedora-buildsys-list mailing list > Fedora-buildsys-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-buildsys-list > > From jkeating at redhat.com Wed Jan 31 20:11:58 2007 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 31 Jan 2007 15:11:58 -0500 Subject: pungi ignores a lot of RPMs when building CD image In-Reply-To: References: <200701311311.11648.jkeating@redhat.com> Message-ID: <200701311512.01711.jkeating@redhat.com> On Wednesday 31 January 2007 14:47, Remy Bohmer wrote: > Thanks for your excellent help on this, I will try this pkgorder > suggestion immediately tomorrow morning... It is evening here in the > Netherlands, and I do not have the CD-build stuff at home... > BTW: Do you prefer contact through this mailinglist, or IRC ? Given our timezone differences, mail is probably best (: -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jeroen.janssen at gmail.com Wed Jan 31 21:44:14 2007 From: jeroen.janssen at gmail.com (Jeroen Janssen) Date: Wed, 31 Jan 2007 22:44:14 +0100 Subject: Mock "Could not find useradd in chroot, maybe the install failed?" In-Reply-To: <45BE2921.2010208@redhat.com> References: <45BE2921.2010208@redhat.com> Message-ID: Well, I removed mock & my modified /etc/mock config files, reinstalled mock and now I can run mock without any problems. So it seems I probably misconfigured mock somehow. Best regards, Jeroen Janssen On 1/29/07, Clark Williams wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Jeroen Janssen wrote: > > Hi, > > > > I have been trying to build F7Test1 for a couple of days now, but I > > seem to be doing something wrong. Since I'm running a FC6 (latest > > updates) system, I need to run pungi within mock in order to generate > > the F7Test1 installation media. > > > > However, I can't seem to get mock to work, so I cannot build the > > installation media. > > > > As a test, I'm running the following: > > mock --debug -r fedora-6-i386-core init > > > > and the latest part of the output is: > > > > DEBUG: Executing /usr/sbin/mock-helper yum --installroot > > /var/lib/mock/fedora-6-i386-core/root update > > Could not find useradd in chroot, maybe the install failed? > > ending > > > > I get the same error when trying to setup a mock for fedora-devel. > > > > This is with mock 0.6.10-1.fc6, with the default mock configfiles. > > > > Anyone here having the same problem, or is it just me? > > > > Best regards, > > > > Jeroen Janssen > > Well, I was going to say that it might not be in the path, since > mock-helper doesn't inherit a path, but /usr/sbin is in that path and > that's usually where useradd is found. > > After a failure, try running : > > mock -r fedora-6-i386-core --no-clean shell > > and poke around in the chroot. Is useradd actually there? > > Clark > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.6 (GNU/Linux) > Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org > > iD8DBQFFvikhHyuj/+TTEp0RArJ0AJ9VwwFsg2bG8VpPnKvY0AtheJnrKwCffNEO > +E8neXWDzYJbxu/JbpCC1pQ= > =tPgs > -----END PGP SIGNATURE----- > > -- > Fedora-buildsys-list mailing list > Fedora-buildsys-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-buildsys-list >