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

RE: mach/mock and selinux



[ ... ]
> >> >>>$ mock -r fedora-3-i386-core mock-0.1-1.src.rpm
> >> > ::
> >> >>> Non-zero return value 127 on executing /usr/sbin/mock-helper 
> >> >>>chroot /var/lib/mock//fedora-3-i386-core/root 
> /sbin/runuser - root 
> >> >>>-c "/usr/sbin/useradd -u 500 -d /builddir mockbuild"
> >> >
> >> > Ok I haven't tested, but apparently this is caused by using 
> >> > selinux, which presumably also explains the problem I was seeing 
> >> > earlier with mach.
> >> 
> >> SELinux was never designed to work with or in chroot environments, 
> >> and unless somebody implements another kernel API, this will not 
> >> change. So best would be, to disable SELinux completely at system 
> >> start.
> >
> > Correct, Enrico, but wouldn't make sense to give user mock all 
> > (selinux) permission for /var/lib/mock!?
> 
> Probably not. SELinux requires the /proc and /selinux 
> filesystems to communicate with the kernel; it does not use 
> the common syscall interface.
> 
> This makes e.g. the 'rpm --root' commands nearly impossible: 
> script execution would require complicated actions in the 
> selinux lib (getting fd of /proc/self/attr/... before the 
> chroot(2) (perhaps of files in /selinux/... also) and using 
> it after the chroot(2)). But the SELinux lib was not designed 
> for it; most functions are doing 'fopen("/proc/...")' 
> themself and can not used cached fd's or other SELinux information.
> 
> See https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=145770 also.

Argh... You are correct, you was thinkin' the other way round... Simply
forget it... :-)

Best,
 Oliver


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