Extras build system back up
by Dan Williams
Hi,
We're back up and using the latest plague code. yum update your
plague-client and you should be good to go.
Dan
17 years, 7 months
mock launcher changes checked into head of CVS
by Clark Williams
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
The branch for mock 0.6 has been cut and my modifications for the new
launcher mechanism have been checked into the head of CVS (which is
now at 0.7). Please pull the new stuff and beat on it. You'll need to
clean up the links in /etc/mock, since there are no fedora-6-* config
files yet. Sorry about that...
I'm not completely sure I have things right wrt to uid/gid
manipulations. I'd appreciate a critical eye being cast on that
portion of the code.
Michael, I stuffed the flock calls in, around the state file write.
Just wanted to see what they'd do and I forgot when I did my check in.
Easy enough to back out if we decide they're not needed.
Clark
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
iD8DBQFEoqsMHyuj/+TTEp0RAp4AAJ94Wu8doF5En6WUFjdfsM5RcAjw+wCdFYMz
8YbPBDQr2+mFyIiySKIJ2sY=
=yEDy
-----END PGP SIGNATURE-----
17 years, 11 months
New version of mock working (I think)
by Clark Williams
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
All,
The inside-out version of mock (or upside-down, depending on your
perspective) seems to be working. For those that don't know what I'm
talking about, we've been looking at changing the way mock deals with
uid/gid manipulation to improve security a bit. The old way was for
/usr/bin/mock to be a link to mock.py and whenever mock wanted to do
something that required root privilege, it called a setuid root
program called /usr/sbin/mock-helper. This program knew how to do a
select few commands (chroot, mount, etc.) and did some argument
validation. Unfortunately mock-helper has some security issues and
extending it would require us to write more C code. While most of us
aren't afraid of writing C code, writing *secure* C code is not simple
and in this case it's probably not worth the effort.
Someone (Michael?) suggested that we turn everything around and write
a simple setuid root/setgid mock launcher program that would then
start mock.py and allow it to manipulate privilege from python code.
I wrote the first cut at a launcher and then added code to mock.py to
elevate and drop privileges around commands that needed it. I now have
a set of code that will build simple SRPMS (elinks, rsync, tar, etc.)
and would like to get some other eyeballs on this code. The "new"
organization is we have a /usr/bin/mock that is a setuid C program
which only knows how to exec /usr/bin/mock.py.
While none of the changes are massive, they are spread across a few
files (Makefile, mock.py, mock.spec, etc/default.cfg, src/Makefile,
src/mock.c) so I'm wondering if I should just blast out the files to
the list, or if I should cut a branch in CVS and let people look at it
from there? Or, should I just check it in and if the consensus is that
it sucks, we can change or revert?
Thoughts?
Clark
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
iD8DBQFEmZwMHyuj/+TTEp0RAsyIAJ9Q2p6qo4SDAc+Je8FAg6GvB6KwVACgum1b
WZnKm0kdjPFob0k3aQQG8aU=
=ry4/
-----END PGP SIGNATURE-----
17 years, 11 months
Branch mock CVS today?
by Clark Williams
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
I didn't get any reply on my question about CVS manipulation, so I
thought I'd start a new thread.
The HEAD of mock's CVS tree is currently at v0.6. I'd like to branch
that so that we have a safe point to drop back to, before we move to
the new launcher, add some file locking or whatever we decide to do
for reporting status, etc.
To do that, I'm proposing the following in CVS:
$ cvs co mock
$ cd mock
$ cvs tag mock-0-6-branchpoint
$ cvs tag -r mock-0-6-branchpoint -b mock-0-6-branch
Theoretically, this will create a static tag (the branchpoint tag) and
then create a branch named mock-0-6-branch, based on the branchpoint
tag. We can then do our wild-and-crazy checkins to head and know that
we have a safe haven.
I'm not wedded to the names or the methodology (that's just how we
tend to manage branches in my group).
If no one has any suggestions or objections, I'll branch later this
afternoon (US Central time) and we can start putting the new code in
and testing.
Clark
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
iD8DBQFEoWXXHyuj/+TTEp0RAsC8AKCY2nfmuuRtUyXzk01MxWJa6bcUYQCfdYn7
Wg7vMZFDutSFm2K5i+GYSAA=
=FXyD
-----END PGP SIGNATURE-----
17 years, 11 months
Default config file contents
by Michael E Brown
Discussion topic:
With the recent changes to mock, several default config file options
have changed. I am of the opinion that we should provide a config file
with only the basic things that the user would like to change, and leave
the defaults in mock.py (with an option to dump the config). For
example, I believe we should take out the mount, unmount, rm, chroot,
etc from our default configs, as it is highly unlikely that average
users would change these.
The reason for this proposed change is to make it easier to migrate from
one version to the next. As it is, mock 0.7 will not be able to use
%config(noreplace) on the config files, because too many things changed.
The user will have to manually merge any site-specific changes.
The final config file, I believe, should only contain the yum config
relating to repository locations, which the user is likely to want to
mirror for speed reasons.
Comments?
--
Michael
17 years, 11 months
First srpm built with new mock launcher + modified mock.py
by Clark Williams
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
I actually built an SRPM last night, using a moderately hacked mock.py
with the new mock launcher.
After figuring out what Michael meant wrt uid/gid manipulation, I went
into mock.py and added two methods to the Root class:
elevate() - change uid to the effective uid (i.e. root)
drop() - change uid back to real uid (i.e. your user id)
I modified the startup code to save off effective and real uids and to
set the realgid to the mock group. I then bracketed calls to "do" that
require privileges (e.g. chroot, mount, etc.) to look like this:
self.elevate()
self.do(<privileged command>)
self.drop()
I had an elinks srpm hanging around and fired off a mock build of that
package, which after finding a couple of calls that needed privileges,
worked (I'm always amazed when that happens). Admittedly it's not a
complex build, but it's a start.
One thing I'm puzzled about is that the build worked on a system
running SELinux and currently the SELinux preload isn't being done.
Anyone have an example build that bombs because of SELinux when the
LD_PRELOAD isn't done?
I need to do a little tidying up of mock.py. The cache stuff is
completely broken because the actual pack/unpack logic is in the
now-defunct mock-helper. I got started moving it into mock.py, but was
overcome with sleepiness last night and didn't finish. I'll try and
send out a mock.py to the list today (or would you rather have a
patch?). Just wanted some eyeballs on it to see if it's going in the
right direction.
Clark
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
iD8DBQFEkWxuHyuj/+TTEp0RAhKNAJ0UNRD78/MRAZPe44ED/CWl8bRongCgwTbR
Cmv9TG+KS2JYplFs6R7lVG8=
=5hTr
-----END PGP SIGNATURE-----
17 years, 11 months
First cut a new mock launcher
by Clark Williams
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Attached is the C source that is my first attempt at a mock launcher
program. This program is built as the executable /usr/bin/mock with
setuid:root, setgid:mock and will exec python with the input file
/usr/bin/mock.py. The program successfully launches python, but I
haven't worked through all the issues to complete a build (yet). I
know that mock.py needs to be modified to remove the dont-run-as-root
test and I've made a first cut at removing mock-helper from .cfg
files, but I'm sure there are other things that need to be done. I
have checked nothing into CVS at this point and even if/when I do, I
suspect I'll be working off a branch for a while.
Note that the program makes use of Linux namespaces. This *should*
make our handling of mount points within the chroot (/proc, /sys,
etc.) a bit easier to clean up, since when the process dies the mounts
should just go away. I haven't verified this though, so caveat emptor.
Anyway, it's a starting point. Please look it over and provide feedback.
Clark
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
iD8DBQFEkC9DHyuj/+TTEp0RAq+4AKCn4hj3bGInJBMWd1Bj6h1SMeCV+QCgt3NW
hPHE9hW9DXL9ZkPLbaJrL6Y=
=XtsC
-----END PGP SIGNATURE-----
17 years, 11 months
Second pass at a mock launcher
by Clark Williams
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Attached is the second pass after comments from Michael and Mike.
- -- removed conditional compile of debugging prints
- -- added MOCKDEBUG environment variable to turn on debug prints
- -- removed usage() function (allow mock.py to report)
- -- removed privilege change code (allow mock.py to manage uid/gid)
- -- removed SELinux LD_PRELOAD code (allow mock.py to manage)
Again, comments/criticism welcome.
Clark
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
iD8DBQFEkHxMHyuj/+TTEp0RAnsTAJ4hjY5MWKDsn6cfS6roN33R1wonhQCfdudU
WXJaNXSQJ/R5i3F/z/i1fvQ=
=nTbj
-----END PGP SIGNATURE-----
17 years, 11 months