-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hello all,
I was poking around in the mock source last week and did some minor refactoring, a couple of name-changes and tried out the rpmlint request. Attached below is a CVS diff of my mock.py with the head of CVS. Please review and comment. A quick summary of the changes:
1. Changed version to 0.7. 2. Added code to avoid exec'ing mount for proc, sys, and dev/pts if we've already done it 3. Oh yeah, added /sys to chroot mount 4. Refactoring: renamed _mount to _mountall, created _mount routine that is called by _mountall 5. Renamed _umount_by_file to _umountall 6. Added code to run rpmlint 7. Added elevate/drop around raw chroot command
I'd especially like some thought on #7, since any time you elevate and drop you can introduce a security hole and I freely admit that I'm not always thinking security first.
If I don't get any push-back (or if I do and then get things resolved), I'll commit these later this week.
Clark
I am leaving for OLS 2006 and wont be able to do any review for the next week.
I just caught up on the rpmlint discussion, and have a few concerns. -- Security of installing just-built RPM -- Can rpmlint just be done outside of mock (using mock chroot, for example)? Why do we have to extend mock for this?
-- Michael
-----Original Message----- From: fedora-buildsys-list-bounces@redhat.com [mailto:fedora-buildsys-list-bounces@redhat.com] On Behalf Of Clark Williams Sent: Monday, July 17, 2006 10:29 AM To: Discussion of Fedora build system Subject: proposed mock changes (diff)
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hello all,
I was poking around in the mock source last week and did some minor refactoring, a couple of name-changes and tried out the rpmlint request. Attached below is a CVS diff of my mock.py with the head of CVS. Please review and comment. A quick summary of the changes:
- Changed version to 0.7.
- Added code to avoid exec'ing mount for proc, sys, and
dev/pts if we've already done it 3. Oh yeah, added /sys to chroot mount 4. Refactoring: renamed _mount to _mountall, created _mount routine that is called by _mountall 5. Renamed _umount_by_file to _umountall 6. Added code to run rpmlint 7. Added elevate/drop around raw chroot command
I'd especially like some thought on #7, since any time you elevate and drop you can introduce a security hole and I freely admit that I'm not always thinking security first.
If I don't get any push-back (or if I do and then get things resolved), I'll commit these later this week.
Clark
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.4 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
iD8DBQFEu6y9Hyuj/+TTEp0RAgumAJ9STO3Qc/7Ca4xYNdIAifcKs4oPvACgqpDD zOm5eNJ1Gwsgc4KqhS8WW0s= =0mBy -----END PGP SIGNATURE-----
"MEB" == Michael E Brown Michael_E_Brown@Dell.com writes:
MEB> I just caught up on the rpmlint discussion, and have a few MEB> concerns.
MEB> Security of installing just-built RPM
Can't be any worse than actually building the package, can it?
MEB> Can rpmlint just be done outside of mock (using mock chroot, for MEB> example)?
Yes, as long as mock continues to give me a way to run a command in the chroot and some equivalent of "mock-helper yum". I was just asking for a way to do it, not that it actually be added as base functionality.
- J<
-----Original Message----- From: fedora-buildsys-list-bounces@redhat.com [mailto:fedora-buildsys-list-bounces@redhat.com] On Behalf Of Jason L Tibbitts III Sent: Monday, July 17, 2006 2:44 PM To: Discussion of Fedora build system Subject: Re: proposed mock changes (diff)
"MEB" == Michael E Brown Michael_E_Brown@Dell.com writes:
MEB> I just caught up on the rpmlint discussion, and have a few MEB> concerns.
MEB> Security of installing just-built RPM
Can't be any worse than actually building the package, can it?
Building package happens as user running mock, not root. Package install happens as root.
MEB> Can rpmlint just be done outside of mock (using mock chroot, for MEB> example)?
Yes, as long as mock continues to give me a way to run a command in the chroot and some equivalent of "mock-helper yum". I was just asking for a way to do it, not that it actually be added as base functionality.
Ok, cool. I think this is the way to go with this, then. -- Michael
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Jason L Tibbitts III wrote:
"MEB" == Michael E Brown Michael_E_Brown@Dell.com writes:
MEB> Can rpmlint just be done outside of mock (using mock chroot, for MEB> example)?
Yes, as long as mock continues to give me a way to run a command in the chroot and some equivalent of "mock-helper yum". I was just asking for a way to do it, not that it actually be added as base functionality.
Well, there I was about to tell you to do this:
$ mock --no-clean chroot yum install foo $ mock --no-clean chroot rpmlint -vi foo
Then I thought, hey, I should try that first (what a concept, eh?). I did and about that time I realized that we don't install yum into the chroot (chroot manipulations occur outside the chroot). So what I did above won't work.
Now, I really don't like the idea of adding *anything* to the default build chroot (other than what's required to build a package). It's slow enough as it is and for the most common usage (plague/mock builds) we don't want anything except what's absolutely needed. So, how would we go about managing a chroot for tasks like testing? Do we add an 'install' command to install stuff from the configured repositories into the chroot, like this:
$ mock install rpmlint
Or do we do something else? Do we make tester's put together their own cfg with a modified buildsys-build rpm that includes the packages they need? Is there a simpler mechanism for someone that wants a chroot for testing?
Clark
Clark
On Jul 17, 2006, at 4:57 PM, Clark Williams wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Jason L Tibbitts III wrote:
> "MEB" == Michael E Brown Michael_E_Brown@Dell.com writes:
MEB> Can rpmlint just be done outside of mock (using mock chroot, for MEB> example)?
Yes, as long as mock continues to give me a way to run a command in the chroot and some equivalent of "mock-helper yum". I was just asking for a way to do it, not that it actually be added as base functionality.
Well, there I was about to tell you to do this:
$ mock --no-clean chroot yum install foo $ mock --no-clean chroot rpmlint -vi foo
Then I thought, hey, I should try that first (what a concept, eh?). I did and about that time I realized that we don't install yum into the chroot (chroot manipulations occur outside the chroot). So what I did above won't work.
Now, I really don't like the idea of adding *anything* to the default build chroot (other than what's required to build a package). It's slow enough as it is and for the most common usage (plague/mock builds) we don't want anything except what's absolutely needed. So, how would we go about managing a chroot for tasks like testing? Do we add an 'install' command to install stuff from the configured repositories into the chroot, like this:
$ mock install rpmlint
Or do we do something else? Do we make tester's put together their own cfg with a modified buildsys-build rpm that includes the packages they need? Is there a simpler mechanism for someone that wants a chroot for testing?
Clark
I've always just used yum from the host system with the --installroot flag. You don't want to rely upon the RPM tools inside of the chroot because those won't always work - remember, we are doing all the package installs with the host system's yum in the first place. My vote would be to keep mock as simple/minimal as possible.
-Jeff
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Jeff Sheltren wrote:
On Jul 17, 2006, at 4:57 PM, Clark Williams wrote:
Now, I really don't like the idea of adding *anything* to the default build chroot (other than what's required to build a package). It's slow enough as it is and for the most common usage (plague/mock builds) we don't want anything except what's absolutely needed. So, how would we go about managing a chroot for tasks like testing? Do we add an 'install' command to install stuff from the configured repositories into the chroot, like this:
$ mock install rpmlint
Or do we do something else? Do we make tester's put together their own cfg with a modified buildsys-build rpm that includes the packages they need? Is there a simpler mechanism for someone that wants a chroot for testing?
Clark
I've always just used yum from the host system with the --installroot flag. You don't want to rely upon the RPM tools inside of the chroot because those won't always work - remember, we are doing all the package installs with the host system's yum in the first place. My vote would be to keep mock as simple/minimal as possible.
Ah, I hadn't thought about that. RPM and friends work fine in the FC5 chroot on my FC5 laptop, but I'm betting an FC2 chroot would yak all over the place. :)
So someone wanting to put together a testing chroot would do something like this:
$ mock -r fedora-5-i386-core init $ yum --installroot=/var/lib/mock/fedora-5-i386-core/root - --enablerepo=<my FC5 repo> install <my packages> $ mock -r fedora-5-i386-core chroot <my test command>
I probably don't have that yum command right, but you should get my intent. Is that the way you use it?
Clark
On Monday 17 July 2006 19:02, Clark Williams wrote:
$ mock -r fedora-5-i386-core init $ yum --installroot=/var/lib/mock/fedora-5-i386-core/root --enablerepo=<my FC5 repo> install <my packages> $ mock -r fedora-5-i386-core chroot <my test command>
I probably don't have that yum command right, but you should get my intent. Is that the way you use it?
Yes, that's how we run buildinstall for Fedora tree spinning.
mock -r dist-fc6 init mockhelper yum --installroot=/var/lib/mock/dist-fc6-<reponumber>/root anaconda-runtime mock -r dist-fc6 chroot buildinstall <lots of options here>
Of course, in there we have a mount call so that we run buildinstall against an NFS mount and write back out to said NFS mount.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Michael_E_Brown@Dell.com wrote:
I am leaving for OLS 2006 and wont be able to do any review for the next week.
I just caught up on the rpmlint discussion, and have a few concerns. -- Security of installing just-built RPM -- Can rpmlint just be done outside of mock (using mock chroot, for example)? Why do we have to extend mock for this?
We don't really have to. I wondered if it could be done without a major upheaval in the code. Turns out it can if we're just talking about running it against the package files. But it would take quite a bit more to do it automagically against an installed package (i.e. install the just-built package into the chroot and run rpmlint on the installed package(s)).
My thought is that running rpmlint against the just-generated RPM/SRPMs is a nice thing to have around, so that a developer could get a regular sanity check on the package (since the results are kept in an rpmlint.log file). Note that you'd still have to invoke mock with the --rpmlint command line option. I think that installing the package in a chroot and doing more extensive testing is job for a testing tool (not mock).
So left to myself I'd probably add the --rpmlint option as is and let someone use 'mock --no-clean chroot <commands>' to do more extensive testing. But I don't feel strongly enough about it that I'd argue for it in the face of determined resistance.
Clark
On Mon, 2006-07-17 at 15:18 -0500, Clark Williams wrote:
My thought is that running rpmlint against the just-generated RPM/SRPMs is a nice thing to have around, so that a developer could get a regular sanity check on the package (since the results are kept in an rpmlint.log file). Note that you'd still have to invoke mock with the --rpmlint command line option. I think that installing the package in a chroot and doing more extensive testing is job for a testing tool (not mock).
+1
-sv
buildsys@lists.fedoraproject.org
-
Clark Williams -
Jason L Tibbitts III -
Jeff Sheltren -
Jesse Keating -
Michael E Brown -
seth vidal