Stephen Smalley wrote:
On Wed, 2006-08-09 at 09:27 +0100, Paul Howarth wrote:
On Thu, 2006-07-13 at 17:59 +0100, Paul Howarth wrote:
Daniel J Walsh wrote:
Paul Howarth wrote:
Daniel J Walsh wrote:
Paul Howarth wrote:
I use mock to build packages for old distributions in a chroot-ed
environment on my FC5 box. I've pretty well got this working for all
old
distributions now apart from FC2 (see
http://www.fedoraproject.org/wiki/Legacy/Mock). On FC2, the process
gets
off to quite a good start, installing the following packages into the
chroot:
=============================================================================
Package Arch Version Repository
Size
=============================================================================
Installing:
buildsys-build noarch 0.5-1.CF.fc2 groups
1.8 k
Installing for dependencies:
SysVinit i386 2.85-25 core
96 k
basesystem noarch 8.0-3 core
2.7 k
bash i386 2.05b-38 core
1.5 M
beecrypt i386 3.1.0-3 core
64 k
binutils i386 2.15.90.0.3-5 core
2.8 M
buildsys-macros noarch 2-2.fc2 groups
2.1 k
bzip2 i386 1.0.2-12.1 core
48 k
bzip2-libs i386 1.0.2-12.1 core
32 k chkconfig i386 1.3.9-1.1 core
99 k
coreutils i386 5.2.1-7 core
2.8 M
cpio i386 2.5-6 core
45 k
cpp i386 3.3.3-7 core
1.4 M
cracklib i386 2.7-27.1 core
26 k
cracklib-dicts i386 2.7-27.1 core
409 k
db4 i386 4.2.52-3.1 core
1.5 M
dev i386 3.3.13-1 core
3.6 M
diffutils i386 2.8.1-11 core
205 k
e2fsprogs i386 1.35-7.1 core
728 k
elfutils-libelf i386 0.95-2 core
36 k
ethtool i386 1.8-3.1 core
48 k
fedora-release i386 2-4 core
92 k
file i386 4.07-4 core
242 k
filesystem i386 2.2.4-1 core
18 k
findutils i386 1:4.1.7-25 core
102 k
gawk i386 3.1.3-7 core
1.5 M
gcc i386 3.3.3-7 core
3.8 M
gcc-c++ i386 3.3.3-7 core
2.0 M
gdbm i386 1.8.0-22.1 core
26 k
glib i386 1:1.2.10-12.1.1 core
134 k
glib2 i386 2.4.8-1.fc2 updates-released
477 k
glibc i686 2.3.3-27.1 updates-released
4.9 M
glibc-common i386 2.3.3-27.1 updates-released
14 M
glibc-devel i386 2.3.3-27.1 updates-released
1.9 M
glibc-headers i386 2.3.3-27.1 updates-released
530 k
glibc-kernheaders i386 2.4-8.44 core
697 k
grep i386 2.5.1-26 core
168 k
gzip i386 1.3.3-12.2.legacy updates-released
88 k
info i386 4.7-4 updates-released
147 k
initscripts i386 7.55.2-1 updates-released
906 k
iproute i386 2.4.7-14 core
591 k
iputils i386 20020927-13 core
92 k
less i386 382-3 core
85 k
libacl i386 2.2.7-5 core
15 k
libattr i386 2.4.1-4 core
8.6 k
libgcc i386 3.3.3-7 core
33 k
libselinux i386 1.11.4-1 core
45 k
libstdc++ i386 3.3.3-7 core
240 k
libstdc++-devel i386 3.3.3-7 core
1.3 M
libtermcap i386 2.0.8-38 core
12 k
make i386 1:3.80-3 core
337 k
mingetty i386 1.07-2 core
18 k
mktemp i386 2:1.5-7 core
12 k
modutils i386 2.4.26-16 core
395 k
ncurses i386 5.4-5 core
1.5 M
net-tools i386 1.60-25.1 updates-released
311 k
pam i386 0.77-40 core
1.9 M
patch i386 2.5.4-19 core
61 k
pcre i386 4.5-2 core
59 k
perl i386 3:5.8.3-18 core
11 M
perl-Filter i386 1.30-5 core
68 k
popt i386 1.9.1-0.4.1 updates-released
61 k
procps i386 3.2.0-1.2 updates-released
176 k
psmisc i386 21.4-2 core
41 k
redhat-rpm-config noarch 8.0.28-1.1.1 core
41 k
rpm i386 4.3.1-0.4.1 updates-released
2.2 M
rpm-build i386 4.3.1-0.4.1 updates-released
437 k
sed i386 4.0.8-4 core
116 k
setup noarch 2.5.33-1 core
29 k
shadow-utils i386 2:4.0.3-55 updates-released
671 k
sysklogd i386 1.4.1-16 core
65 k
tar i386 1.13.25-14 core
351 k
termcap noarch 11.0.1-18.1 core
237 k
tzdata noarch 2005f-1.fc2 updates-released
449 k
unzip i386 5.50-37 core
139 k
util-linux i386 2.12-19 updates-released
1.5 M
which i386 2.16-2 core
21 k
words noarch 2-22 core
137 k
zlib i386 1.2.1.2-0.fc2 updates-released
44 k
After installing all of these packages successfully, the next thing
that
happens is:
Executing /usr/sbin/mock-helper
chroot /var/lib/mock/fedora-2-i386-core/root /bin/su - root -c
"/usr/sbin/useradd -m -u 500 -d /builddir mockbuild"
and at that point the "useradd" process just hangs indefinitely. I'm
told that if SELinux is disabled (I've tried permissive mode and that
doesn't help), this works. I can't see any AVCs in the logs.
Any ideas what might be causing this and how it might be fixed?
In fc2 you should disable SELinux.
I'm running this on FC5; what I'm trying to do is set up a chroot with
FC2 packages. This includes the FC2 version of useradd, and it's this
that's hanging when run in the chroot.
I'd happily give things in the chroot the impression that SELinux is
disabled (I believe mock actually does this already) but I *really*
don't want to disable SELinux on my FC5 host.
Paul.
I have no idea why this would happen then. And I am not sure I believe
them when they say that if SELinux was disabled this would work
differently, unless there is a kernel bug. You are not seeing avc
messages, correct?
Correct.
Usually if it does not work in permissive mode it is
not an SELinux problem.
*Usually*...
I guess I'll have to bite the bullet and try it with SELinux disabled
(so I'll have to relabel my desktop box afterwards, sigh). I know of two
people that have this working with SELinux disabled, and I vaguely
recall it working for me when I was first trying this (with SELinux
disabled, probably a year ago). I've got it working for everything from
RHL7 through to FC5 targets apart from FC2, so I doubt I'm doing
something significantly wrong.
I've now got a nice shiny new x86_64 box so at last I've been able to
sacrifice my old build system by disabling SELinux on it. My
recollection was correct - the mock build for FC2 worked just fine with
SELinux disabled.
Any thoughts on what might be going on here?
Did you ever try stracing the useradd process to see what it is doing at
the point where it hangs?
It's a bit fiddly to do this for mock because it runs all "root"
commands through an SUID helper that checks what it's running. However,
by adding the following line to the FC2 mock config line, I think I may
have turned something up:
config_opts['chroot'] = '/usr/bin/strace /usr/sbin/mock-helper chroot'
With this set, the build actually seems to get further than the
"useradd", though the "useradd" does in fact fail because the chroot is
refused:
execve("/usr/sbin/chroot", ["chroot",
"/var/lib/mock/fedora-2-i386-core"..., "/bin/su", "-", "root", "-c",
"/usr/sbin/useradd -m -u 500 -d /"...], [/* 2 vars */]) = 0
brk(0) = 0x505000
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0)
= 0x2aaaaaaab000
uname({sys="Linux", node="metropolis.intra.city-fan.org", ...}) = 0
access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or
directory)
open("/etc/ld.so.cache", O_RDONLY) = 5
fstat(5, {st_mode=S_IFREG|0644, st_size=84704, ...}) = 0
mmap(NULL, 84704, PROT_READ, MAP_PRIVATE, 5, 0) = 0x2aaaaaaac000
close(5) = 0
open("/lib64/libc.so.6", O_RDONLY) = 5
read(5, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0P\317\321"...,
832) = 832
fstat(5, {st_mode=S_IFREG|0755, st_size=1653608, ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0)
= 0x2aaaaaac1000
mmap(0x30f6d00000, 2392200, PROT_READ|PROT_EXEC,
MAP_PRIVATE|MAP_DENYWRITE, 5, 0) = 0x30f6d00000
mprotect(0x30f6e3f000, 1048576, PROT_NONE) = 0
mmap(0x30f6f3f000, 20480, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 5, 0x13f000) = 0x30f6f3f000
mmap(0x30f6f44000, 16520, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x30f6f44000
close(5) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0)
= 0x2aaaaaac2000
arch_prctl(ARCH_SET_FS, 0x2aaaaaac2230) = 0
mprotect(0x30f6f3f000, 16384, PROT_READ) = 0
mprotect(0x30f6c19000, 4096, PROT_READ) = 0
munmap(0x2aaaaaaac000, 84704) = 0
brk(0) = 0x505000
brk(0x526000) = 0x526000
chroot("/var/lib/mock/fedora-2-i386-core/root") = -1 EPERM (Operation
not permitted)
write(2, "chroot: ", 8chroot: ) = 8
write(2, "cannot change root directory to "..., 69cannot change root
directory to /var/lib/mock/fedora-2-i386-core/root) = 69
write(2, ": Operation not permitted", 25: Operation not permitted) = 25
write(2, "\n", 1
) = 1
close(1) = 0
exit_group(1) = ?
Process 2287 detached
So, any thoughts on why the "Operation not permitted" for the chroot
would happen? Is this to do with running under strace, or is it the
underlying issue?
All "chroot" calls seem to have failed in the trace.
Without the strace, I know the "/builddir" directory (which is to be the
home directory of the added user) isn't created, so I suspect that
running under strace isn't the problem in itself.
Paul.
--
fedora-selinux-list mailing list
fedora-selinux-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-selinux-list
