Bug#560348: xen: using SELinux and a Linux kernel stored under `/tmp/` (was: racy temporary files for kernel and initrd)
On Thu, 12 Aug 2010, Paul Menzel <pm.debian@googlemail.com> wrote:
> > > I took a look where `VmError` originates from. I think, it turns out to
> > > be in `/usr/lib/xen-3.2-1/lib/python/xen/xend/image.py`.
> > >
> > > if not os.path.isfile(self.kernel):
> > > raise VmError('Kernel image does not exist: %s' %
> > > self.kernel)
If stat() fails due to EPERM then I'm guessing the isfile() returns false, in
which case that error message isn't as helpful as it could be.
> > > But testing this manually works.
> > >
> > > $ python
> > >
> > > >>> import os
> > > >>> os.path.isfile("/tmp/vmlinuz")
> > >
> > > True
> >
> > Very strange.
So we are instructing the xend to do something, in which case you should label
your test program with the same context as the xend. Something like the
following command will do:
chcon --reference=/usr/lib/xen-4.0/bin/xend /tmp/mytest.py
Changing the file names for the test program and the xend as appropriate.
> I also tried the above script with `sudo python` and I got the same
> result (»True«).
If it's an SE Linux issue then sudo shouldn't change things.
> SELinux is running on my system. But I changed it into permissive mode
> back then when debugging and that did not change anything either. But I
> do not know much about SELinux, so I just blame it for now. :(
If the problem occurs in permissive mode then it's almost certainly not SE
Linux.
--
russell@coker.com.au
http://etbe.coker.com.au/ My Main Blog
http://doc.coker.com.au/ My Documents Blog
Reply to: