buildsys June 2006

buildsys@lists.fedoraproject.org

20 participants
21 discussions

mock 0.6
by seth vidal 13 Jun '06

13 Jun '06

Hi folks, I just pushed out mock 0.6 to: http://fedoraproject.org/projects/mock/releases/ This should be everything that we've talked about over the last couple of weeks with properly fixed config files. With this release I'm going to step away from managing mock. I've not had the time to devote to it and there are people who are much more motivated and just downright smarter who have stepped up to be lead maintainers. Michael Brown and Clark Williams have volunteered (been volunteered) to take over mock maintenance/development. I'll continue to be around but I'll hang back in the inky shadows and serve as a tiebreaker, if needed. Anyway - please give this release a test and make sure it looks happy on your machines. If it does I'll push the changes out to fedora extras, as well. Thanks, -sv

1 0

Discussion summary: Mock security
by Michael E Brown 09 Jun '06

09 Jun '06

Current mock contains one SUID program, mock-helper, that can be run only by people in the 'mock' group. This helper script performs many actions as root that cannot be done by the main mock python executable. There is one question we need to answer in regards to the current mock-helper security model. -- Should we allow untrusted users access to the 'mock' group? If we answer 'yes' to this question, that implies that we must make mock-helper bulletproof for users in the 'mock' group who wish to use mock-helper to leverage access to 'root' on the box. After looking closely at the mock-helper source, I have identified several problematic areas, listed below. I do not believe, given the current state of mock-helper, that we should endorse the idea of allowing untrusted users access to the 'mock' group. We should very prominently label mock as giving, essentially, root access to each user you allow to run it. I believe the wiki, the help text of "mock -h", the mock README, and the mock man page should all be updated with this information. Proposed warning text: ==================================================================== Mock contains a Set-UID helper program that can only be run by users in the 'mock' group. Adding users to the 'mock' group is equivalent to giving them full root access to the OS. Do not add untrusted users to the 'mock' group. Mock is not designed to safely be run by untrusted users. ==================================================================== Problem area: do_mknod() passes unchecked user data to the mknod command. User can use the "-m" to set insecure permissions on, for example, a hard disk device node. Proposed Solution: Do not pass user-supplied input to mknod. Make an array of allowed devices, along with major/minor and permissions. Mock-helper mknod should only be passed the device name, and it should look up the major/minor/perms from the array. Problem area: do_chroot() passes unchecked user data to chroot command. User can easily get a shell, and, for example, create device nodes. Proposed Solution: Do not pass user-supplied data to chroot. Make an array of allowed commands, mock.py should just pass which command it wants to run from the list. Any required user input should be filtered for [A-Za-z0-9,+\-.], or similarly strict regexp. No extra options should be allowed to the command (for example, no input starting with '-') Problem area: do_rm() does not check all user input. Only checks argv[2] and argv[3], yet passes all args received to rm. User can add new options, as long as they come after argv[3]. User could remove system files by passing as argv[4] or later. Proposed solution: Add check to allow only one argument. Force '-rf' argument. Perform strict validation on the one argument passed. Problem area: do_mount() does not check all user input. User can pass extra args that will be passed to mount unchecked. Proposed solution: array of allowed mounts. Problem area: do_yum() does not check all user input. For example, user could possibly pass an extra --installroot / later in the command. Proposed solution: Check all user input. Disallow extra arguments. Problem area: do_unpack() does not check that tarball is from secure directory. Could contain insecure /dev/ files (see do_mknod()) -- Michael Brown

8 15

Is the push window too big?
by Michael Schwendt 08 Jun '06

08 Jun '06

I think this just broke two build jobs: | Executing /usr/sbin/mock-helper yum --installroot /var/lib/mock/fedora-5-i386-core-e4c5db6c7c922589d8995bf76b50bcc08e68b049/root install 'zlib-devel' 'texi2html' 'compat-gcc-32' 'SDL-devel' | http://buildsys.fedoraproject.org/plague-results/fedora-5-extras/nx/1.5.0-9…: [Errno 4] IOError: HTTP Error 404: Not Found | Trying other mirror. | Error: failure: nx/1.5.0-9.fc5/i386/nx-1.5.0-9.fc5.i386.rpm from local: [Errno 256] No more mirrors to try. | Cleaning up... Am I misinterpreting this, or did this build job fail because the package had been moved away shortly before the job was queued? When I logged into extras64 to sign and push pending builds, the build-status page did not list any running jobs. However, the time it takes to run repomanage, createrepo, repoview and sync the results to the master repository is far too long. It looks like above "qemu" job was started shortly after I had started the push. The push is still in progress while I type this. Especially repoview takes a lot of time, and it is also run for debuginfo packages. (why? is this really worthwhile?) Which repositories do the build servers pull packages from? What options do we have to improve this? - We could modify the push script to _copy_ files instead of moving them. Successfully copied packages would be marked [in their package root directory] and would not be removed prior to a successful sync. - I've heard there is a new createrepo version which makes backups of other files in the repodata directory. With it, we would not lose the repoview directory and could sync twice (once after running createrepo, second time after updating the repoview pages). The first sync would cause the new packages to show up in the master repository much sooner. - One good thing about the new push script is that it mails the build report only after a successful sync, i.e. when the master repository is up-to-date. Is this the only notification for packagers that they can use to decide when to re-queue their build jobs?

3 3

Hiding "removed" lines from mock debug output
by Jason L Tibbitts III 08 Jun '06

08 Jun '06

Would it be reasonable to consider eliminating the "removed `/blah'" lines from mock's debug output or perhaps moving them to another debug level? They swamp the regular debug output (which is often quite useful to watch) and crowd out other useful information in root.log. I know I can always use grep or patch locally, but it gets a bit tedious. - J<

3 2

[PATCH] Allow setting use_cache in config file
by Michael E Brown 06 Jun '06

06 Jun '06

Here is a small patch to allow setting config_opts['use_cache'] in the config file. So you do not have to use --autocache on every cmdline. It also adds a --nocache option, to override cfg file, if necessary. This was the original intent, but wasn't tested. Options are always processed in the config file and overridden by cmdline args. -- Michael

1 0

mock release
by seth vidal 04 Jun '06

04 Jun '06

Hi boys and girls, I'd like to see about getting a mock release out this weekend given all the stuff that's changed and now that we have the 'minimum buildroot' defined by fesco. Is there anything unchecked in that everyone wants to see and feels won't make the world shatter? If I don't hear anything I'm going to make a tarball, test it out and call it 0.6 or something like that and release it this weekend. Thanks, -sv

5 5

Re: policy for mock - put in mock package or selinux-policy-targeted?
by Jeremy Katz 04 Jun '06

04 Jun '06

On Sun, 2006-06-04 at 21:11 +0100, Paul Howarth wrote: > On Sun, 2006-06-04 at 15:18 -0400, Jeremy Katz wrote: > > On Thu, 2006-06-01 at 13:51 -0500, Matt Domsch wrote: > > > Should those files get compiled into modules, and installed, using > > > mock's SRPM, or should they go into selinux-policy-targeted? > > > > Right now, they should go into the main policy package. Work is > > underway to allow reasonable packaging of policy within other packages, > > but there are some dependencies there which need to be handled first. > > I tend to agree, Whilst there are already a few packages in Extras with > custom policy hacks (semanage calls mainly, though pureftpd has a custom > module), there isn't yet a definitive way to do this nice and cleanly > (see the "SELinux Module Packaging in FC5" thread). Yeah -- I was involved in the discussion on the main SELinux list. I've had to generally avoid fedora-selinux-list of late just so that I can keep up with my flood of mail :) > > Also, I'm not 100% convinced that relaxing what mock is allowed to do > > unconditionally like is described there is the best approach. Not that > > anything better is immediately coming to mind at the moment :-/ > > Major problems that need to be overcome in order to do something better > include: > > 1. Mock itself loads a dummy libselinux, which makes everything that > happens under its control believe that SELinux is disabled. *nod* That was done as the simple and easy way of handling things at the time (right before FC3 was released). It may well make more sense to have awareness in the chroots of SELinux being enabled now and handling things accordingly. It should be easy enough to investigate if someone wants to try. > 2. The entire default file context tree in policy (and add-on modules, > semanage-ed custom policy tweaks etc.) would need to be duplicated for > each chroot. Yeah, this is where things start to give me the heebie-jeebies :) Jeremy

1 0

policy for mock - put in mock package or selinux-policy-targeted?
by Matt Domsch 04 Jun '06

04 Jun '06

What's the right place to put application-specific policy modules, such as the mock policy outlined here: http://fedoraproject.org/wiki/Extras/MockTricks Should those files get compiled into modules, and installed, using mock's SRPM, or should they go into selinux-policy-targeted? Seth Vidal wants to push out a new mock build soonish, and this is something I'd like cleared up before that if possible. Thanks, Matt -- Matt Domsch Software Architect Dell Linux Solutions linux.dell.com & www.dell.com/linux Linux on Dell mailing lists @ http://lists.us.dell.com

2 1

Adding a lock file to plague server Repo.py _update_repo()
by Michael Schwendt 02 Jun '06

02 Jun '06

Currently, when we sign and push built packages, we move them out of a "repodir" while the build server may be copying new packages to that directory. We have not cleaned up repodir for a long time either, because it could not be done automatically without risk. The corresponding section in the push script contains a "todo" comment only. [Recently I've used a separate script, however, which cleans up the directory after a push, provided that the build system is idle and no package is about to be copied into the directory at the same time.] I've looked at Repo.py _update_repo() where I see nothing which prevents concurrent access to this repodir. Is there anything I'm missing when thinking that it is possible to add a simple lock file at the root of repodir in order to control access to this directory? The build master would lock the file when copying new packages to it. And the push script would lock the file when moving packages and when cleaning up. Both would sleep when they cannot acquire the lock.

2 5

BuildJob -> PackageJob confusion
by Michael Schwendt 02 Jun '06

02 Jun '06

The ChangeLog doesn't cover this, but there is no BuildJob.py or buildjob.py anymore. Hence references to "BuildJob" objects should be called "PackageJob" to avoid confusion. In particular, in server/Repo.py it should be: s/BuildJob/PackageJob/g s/buildjob/pkgjob/g

2 1

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

buildsys June 2006