naliboat policy # ls -alZ /etc/passwd -rw-r--r-- root root system_u:object_r:etc_t /etc/passwd naliboat policy # useradd -s /bin/false test naliboat policy # ls -alZ /etc/passwd -rw-r--r-- root root prodan:object_r:shadow_t /etc/passwd naliboat policy # ls -al `which useradd` -rwxr-xr-x 1 root root 70652 Jun 30 09:55 /usr/sbin/useradd naliboat policy # ls -alZ `which useradd` -rwxr-xr-x root root system_u:object_r:useradd_exec_t /usr/sbin/useradd naliboat policy # epm -qf `which useradd` shadow-4.0.4.1-r2 problem: on an enforcing machine login will be impossible ( tried :( )
Unfortunately this has been a known problem for a while. Debian also has this problem, but apparently not Fedora. Its unclear why at the moment. Best thing to do right now is use setfiles to relabel it back: echo "/etc/passwd" | setfiles /etc/security/selinux/file_contexts -s
hmm, I guess I've solved this one. after a small strace output comparison between 4.0.3-r9 and 4.0.4.1-r2 I have seen that the new 'useradd' binary was not using ANY selinux-related functions. it looked like WITH_SELINUX was not defined at compile time. which was exactly the case here. although -DWITH-SELINUX was defined in the Makefile.am, it never made his way into Makefile.in and finaly into Makefile the way it was happening in 4.0.3. maybe it's a automake or a timestamp issue, not sure and I care less. so here is a new selinux patch that does the job. can you please consider publishing this new patch?
Created attachment 34721 [details, diff] updated patch
I'll certainly look at it. I'd be happy to get rid of this problem :)
good catch! in shadow-4.0.4.1-r3
