[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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 

http://etbe.coker.com.au/          My Main Blog
http://doc.coker.com.au/           My Documents Blog

Reply to: