python-imgcreate-16.3-1.fc16.x86_64 /usr/lib/python2.7/site-packages/imgcreate/creator.py contains some checks for os.path.exists("/selinux/enforce") selinuxfs has however moved to /sys/fs/selinux , so /selinux is now the wrong place to look. There has been some discussion about creating a symlink from /selinux to /sys/fs/selinux , but that has apparently not happened. (This was a problem for me because I for some reason had some wrong content in /selinux that no longer was hidden by the mounted selinuxfs, and that caused livecd-creator to fail.)
The right thing to do here is support both.
Note that in theory, because /selinux usually is a mount point for selinuxfs, then the directory should be empty when selinuxfs no longer is mounted there. Some machines do have some content in /selinux in the filesystem. It might primarily be systems that has been installed from a livecd, but it also seems like some other tools touches it. Thus, if both locations are supported then it is important that /sys/fs/selinux is searched first. However, AFAIK a livecd-tools version only runs on the one Fedora release and can build the platforms supported at release time, so I doubt there is any reason to look in the old location at all.
Created attachment 516966 [details] Untested Patch Here's a quick patch. Give it a try and let me know. I'll do some testing Monday.
Traceback (most recent call last): File "/usr/bin/livecd-creator", line 187, in <module> sys.exit(main()) File "/usr/bin/livecd-creator", line 169, in main creator.mount(options.base_on, options.cachedir) File "/usr/lib/python2.7/site-packages/imgcreate/creator.py", line 525, in mount booleans = selinux_path() + "/booleans" TypeError: unsupported operand type(s) for +: 'NoneType' and 'str' - which indicates that there now is a problem with the case where there is no selinux path. I do however have selinux (in permissive mode), so the real problem here is however that it looks for .../selinux/enforcing in util.py - it should be .../selinux/enforce. With that fixed my test run seems to succeed. (During the test run I got /usr/bin/chcon: cannot access `/var/tmp/imgcreate-PXqd63/install_root/selinux': No such file or directory which might be a slightly different problem - but apparently related.)
And then, after composing: Traceback (most recent call last): File "/usr/bin/livecd-creator", line 187, in <module> sys.exit(main()) File "/usr/bin/livecd-creator", line 171, in main creator.configure() File "/usr/lib/python2.7/site-packages/imgcreate/creator.py", line 751, in configure kickstart.SelinuxConfig(self._instroot).apply(ksh.selinux) File "/usr/lib/python2.7/site-packages/imgcreate/kickstart.py", line 442, in apply self.relabel(ksselinux) File "/usr/lib/python2.7/site-packages/imgcreate/kickstart.py", line 427, in relabel "/etc/selinux/targeted/contexts/files/file_contexts", "/"]) File "/usr/lib/python2.7/site-packages/imgcreate/kickstart.py", line 124, in call subprocess.call(args, preexec_fn = self.chroot) File "/usr/lib64/python2.7/subprocess.py", line 493, in call return Popen(*popenargs, **kwargs).wait() File "/usr/lib64/python2.7/subprocess.py", line 679, in __init__ errread, errwrite) File "/usr/lib64/python2.7/subprocess.py", line 1228, in _execute_child raise child_exception TypeError: execv() arg 2 must contain only strings - apparently/obviously because selinux isn't available inside the instroot and we thus get a None?
Created attachment 517274 [details] Updated patch Give this one a try. I ran it against the fedora-live-mini.ks and it appeared to work for me (w/o selinux in enforcing mode)
Traceback (most recent call last): File "/usr/bin/livecd-creator", line 187, in <module> sys.exit(main()) File "/usr/bin/livecd-creator", line 171, in main creator.configure() File "/usr/lib/python2.7/site-packages/imgcreate/creator.py", line 754, in configure kickstart.SelinuxConfig(self._instroot).apply(ksh.selinux) File "/usr/lib/python2.7/site-packages/imgcreate/kickstart.py", line 445, in apply self.relabel(ksselinux) File "/usr/lib/python2.7/site-packages/imgcreate/kickstart.py", line 430, in relabel "/etc/selinux/targeted/contexts/files/file_contexts", "/"]) File "/usr/lib/python2.7/site-packages/imgcreate/kickstart.py", line 124, in call subprocess.call(args, preexec_fn = self.chroot) File "/usr/lib64/python2.7/subprocess.py", line 493, in call return Popen(*popenargs, **kwargs).wait() File "/usr/lib64/python2.7/subprocess.py", line 679, in __init__ errread, errwrite) File "/usr/lib64/python2.7/subprocess.py", line 1228, in _execute_child raise child_exception TypeError: execv() arg 2 must contain only strings - because an empty list now in some cases is inserted in the argument list. I propose something like: self.call(["/sbin/setfiles", "-e", "/proc", "-e", "/sys", "-e", "/dev"] + selinux_args + ["/etc/selinux/targeted/contexts/files/file_contexts", "/"]) I end up in this case because util.selinux_path still look for /sys/fs/selinux/enforcing - it should be .../enforce . It also seems incorrect that __create_selinuxfs uses self._instroot + selinux_path() . I thought the whole reason this is a bit tricky is that it should be possible to build livecds where the target os version is different from the build os version and where they thus have different location of selinuxfs. Isn't this version of livecd-tools designed to run on F16 only? Then why not just make the selinuxfs location in the outer system const? And inside the chroot why not just fake selinuxfs in both new and old location or make a symlink? (Note however that the filesystem package still think it owns /selinux - bug 729255)
Quoting dwalsh on bug 729563#c9 : Anaconda should be using selinux python bindings rather the hard coding paths if possible.
Created attachment 517645 [details] This updated patch removes the hard coding of /sys/fs/selinux and looks it up within /proc/self/mountinfo Also uses selinux python binding to find file_context file.
dwalshs patch seems to work for me (in combination with dracut-011-40.git20110810)
What's the impact of this? With the dracut to fix https://bugzilla.redhat.com/show_bug.cgi?id=728863 , and with current livecd-tools / python-imgcreate - i.e. no kind of fix to this bug at all - I was able to generate a live image which seemed to work pretty well (there was a single AVC at boot, which I didn't investigate yet). Unless the impact of this is greater than it currently seems, I'd be -1 blocker.
The impact of this bug varies, depending on the host livecd-creator runs on and whether it has a /selinux directory and what is in it. Some hosts have stale and wrong content there - probably a left over from previous bugs in livecd-creator or anaconda. The consequences of the wrong content also depends on the selinux mode on the host and on the image that is build. I guess the simple workaround is to create a symlink from /selinux to /sys/fs/selinux on all build hosts or chroots (after removing /selinux/ if it exists).
*** Bug 729701 has been marked as a duplicate of this bug. ***
Well without this patch you will see ugly SELinux errors during the build of F16. But it is not necessary to get out this for Alpha if that is why you are asking. I think my patch should be applied. If you find problems with back porting to older versions of the OS, I will revisit the patch.
Right - I should have been clearer, I was coming from the angle of assessing the blocker-iness of this bug, since it's been proposed as an Alpha blocker. I'm not looking at the *validity* of it, just whether we should take it as an Alpha blocker and hence pull the fix through the freeze into Alpha.
Well I guess if the virtual machines work with SELinux in enforcing mode without this fix, then it is not a blocker.
Discussed in the 2011-08-12 blocker review meeting. This bug does not hit any release criteria since the live images are building. Rejected as a blocker for Fedora 16 alpha.
*** Bug 733321 has been marked as a duplicate of this bug. ***
livecd-tools-16.4-1.fc16 has been submitted as an update for Fedora 16. https://admin.fedoraproject.org/updates/livecd-tools-16.4-1.fc16
Package livecd-tools-16.4-1.fc16: * should fix your issue, * was pushed to the Fedora 16 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing livecd-tools-16.4-1.fc16' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/livecd-tools-16.4-1.fc16 then log in and leave karma (feedback).
livecd-tools-16.5-1.fc16 has been submitted as an update for Fedora 16. https://admin.fedoraproject.org/updates/livecd-tools-16.5-1.fc16
livecd-tools-16.6-1.fc16 has been submitted as an update for Fedora 16. https://admin.fedoraproject.org/updates/livecd-tools-16.6-1.fc16
livecd-tools-16.6-1.fc16 has been pushed to the Fedora 16 stable repository. If problems still persist, please make note of it in this bug report.