Description of problem: Sudo level livecd-creator is unable to change or remove the root password. You get the error: passwd: unconfined_u:unconfined_r:livecd_t:s0-s0:c0.c1023 is not authorized to change the password of root cp: cannot stat `/var/tmp/imgcreate-zZMCUH/install_root/usr/share/doc/HTML/readme-live-image/en_US/readme-live-image-en_US.txt': No such file or directory e2fsck 1.41.9 (22-Aug-2009) Version-Release number of selected component (if applicable): livecd-tools-031-1.fc12.1 spin-kickstarts-0.12.0-2.fc12 How reproducible: Steps to Reproduce: 1. ~] $sudo livecd-creator -c /usr/share/spin-kickstarts/fedora-livecd-desktop.ks -f Fedora-12-i686-Live 2. 3. Actual results: Livecd creator unable to remove root password. Expected results: Livecd creator creates removes root password. Additional info:
I have researched a bit more. Setting /etc/sysconfig/selinux/config to permissive on the linux that is actually creating the livecd fixes this error.
Here's a corresponding audit log entry: audit.log.1:type=USER_CHAUTHTOK msg=audit(1260601250.607:153622): user pid=17278 +uid=0 auid=500 ses=26 subj=unconfined_u:unconfined_r:passwd_t:s0-s0:c0.c1023 +msg='op=change password id=0 exe="/usr/bin/passwd" hostname=? addr=? +terminal=pts/1 res=failed'
Fixed in selinux-policy-3.6.32-59.fc12.noarch
I am still seeing a problem with selinux-policy-3.6.32-63.fc12.noarch. It is a different AVC though. Now it doesn't seem to be able to open the live image password file. Probably it's going to need to write the file as well. It looks like the live image password file isn't properly labelled. Does the password need to get changed later? Should the file just be labelled one off or should the password program be allowed to change a file labelled file_t? type=AVC msg=audit(1261531209.109:275): avc: denied { open } for pid=14572 comm="passwd" name="enforce" dev=loop0 ino=393227 scontext=unconfined_u:unconfined_r:passwd_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:file_t:s0 tclass=file
file_t means that the file never had a label on it. Was this file created when the machine had selinux disabled?
I don't know for sure what file it is referring to. The machine shouldn't have any file_t files on it. My guess is that the file is part of the live image that is being created and for some reason isn't getting labelled. The device being loop0 supports that theory.
The passwd utility is trying to read /selinux/enforce to check if the machin is in enforcing mode. Since this file is created by livecd tools it should have gotten created with a label.
This (or something with the same symptoms) is still happening in F13. I forgot to go to permissive when building an x86_64 custom spin and found that I didn't have a usable root password when I went to do the install. And possible related to this is when I booted the live image in runlevel 1, I couldn't set the root password until going to permissive mode.
Things seem to work with selinux-policy-3.7.16-1.fc13.noarch.
This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component.
Closing. Comment 9 says he notices it is fixed with a selinux-policy update. A related Bug 519709 has a patch, related to SELinux file contexts between hosts with SELinux disabled and target images which may have selinux --enforcing in the kickstart files to have contexts. I have updated it to apply clean, and it is ready to be committed to git.