mock 0.6
by seth vidal
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
17 years, 10 months
Discussion summary: Mock security
by Michael E Brown
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
17 years, 10 months
Is the push window too big?
by Michael Schwendt
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...: [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?
17 years, 10 months
Hiding "removed" lines from mock debug output
by Jason L Tibbitts III
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<
17 years, 10 months
[PATCH] Allow setting use_cache in config file
by Michael E Brown
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
17 years, 10 months
mock release
by seth vidal
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
17 years, 10 months
Re: policy for mock - put in mock package or selinux-policy-targeted?
by Jeremy Katz
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
17 years, 10 months
Adding a lock file to plague server Repo.py _update_repo()
by Michael Schwendt
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.
17 years, 10 months
BuildJob -> PackageJob confusion
by Michael Schwendt
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
17 years, 10 months
