Eric Paris wrote: > On Thu, 2008-05-15 at 15:30 -0400, Stephen Smalley wrote: >> On Thu, 2008-05-15 at 13:50 -0400, Eric Paris wrote: >>> So I'm still stumbling along in the dark trying to get livecd-creator to >>> build me a nice new F10 image inside an F10 host. I've actually got an >>> image that built and runs, but not without its issues. >>> >>> my kickstart file has: >>> auth --enableshadow --enablemd5 >>> rootpw redhat >>> >>> but the livecd always has x for the password in /etc/password and * for >>> the password in /etc/shadow. No ideas here I must admit. I'm highly >>> doubtful its selinux since it happens in permissive and enforcing. I >>> have just been booting into single user, calling passwd, init 3, and >>> logging in to play around in my live image.... >> No ideas here - hopefully the livecd folks can help you with that one. > > turns out it was an selinux issue. > > passwd does 2 different checks to see if selinux is going to allow it. > Dan, what were you thinking? I see your name written all of this. > > Anyway selinux_check_passwd_access() calls security_getenforce() and > allows things if it gets 0. Since security_getenforce can't > open /selinux/enforce (it doesn't exist) it returned -1, we then > proceeded to try to do the access check which obviously also bombed (do > to another ENOENT) and passwd gave us that useless "Only root can do > that" message. > > First try was to change selinux_check_passwd_access() to return a > success if security_getenforce() < 1. Which then turned up that passwd > has its own secondary check (WTF?) called check_selinux_access() which > basically did the same thing as the libselinux function. I changed it > to use < 1 and finally got passwd to run inside my chroot. > > I think the best solution here is to explicitly set a /selinux/enforce = > 0 in the chroot rather than hack everything that could possibly call > security_getenforce() what do others think? > > -Eric > Well the code was written 100 years ago or it feels that way anyways. I think the multiple checks are to see if you are root when changing a password and to check whether the domain executing passwd has the rootok passwd access. -- fedora-selinux-list mailing list fedora-selinux-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-selinux-list