Description of problem: rpc.yppasswdd tries to bind to a port# < 1024 when it starts. If it can't do this, it throws: rpc.yppasswdd: can not bind UDP: Permission denied and retries on a non-priv port#. If one forces a low port choice with the --port option, rpc.yppasswdd simply dies. selinux is blocking this attempt to bind. The problem with this: the yppasswd client program refuses to talk to a daemon that's running on port# > 1024, so users cannot change their NIS information. Unfortunately this denial is not logged in audit.log. However, if one does a "setenforce 0" then rpc.yppasswd starts happily. Or, if one does a "setsebool yppasswdd_disable_trans 1" then the daemon also is allowed to bind to the proper port. This is with selinux-policy-targeted-2.4.6-72.fc6, and also might be in the last publicly released version or two (I've not had a chance to track this one down till now, but it's been reported to me for a few weeks). It used to Just Work. Part of the (admittedly lame) security model for NIS is the use of low numbered ports, so not allowing the daemon to use them defeats the tool's own security model.
Fixed in selinux-policy-2.4.6-75
Been checking the fedora-updates-testing repository religiously for the last ten days, but no go. Could you please push the fixed policy rpms? I'll happily test them out. Thanks!
Having some infrastructure problems. You can grab the packages from http://people.redhat.com/dwalsh/SELinux/FC6 I will try to push it to testing today.
Great - I can confirm that this does fix it on my server, thanks!
Ok I got it pushed to fc6 testing.
I hate to re-open this, but there are still bad interactions between selinux and rpc.yppasswd. When I tested that things worked with selinux-policy-2.4.6-75, I must have only checked that the port binding issue was resolved, rather than pushing through a complete cycle of password changing. The client can talk to the yppasswd server ok, but when the server daemon actually tries to update the passwd files, it fails: Jun 27 15:38:15 lepton rpc.yppasswdd[4936]: update xxxx (uid=505) from host 192.168.1.1 failed Jun 27 15:38:15 lepton rpc.yppasswdd[4936]: Can't open /etc/passwd.tmp: Permission denied This time there's an AVC denial: type=AVC msg=audit(1182976695.209:198): avc: denied { dac_override } for pid=4936 comm="rpc.yppasswdd" capability=1 scontext=user_u:system_r:yppasswdd_t:s0 tcontext=user_u:system_r:yppasswdd_t:s0 tclass=capability type=SYSCALL msg=audit(1182976695.209:198): arch=40000003 syscall=5 success=no exit=-13 a0=8011f038 a1=242 a2=1b6 a3=80123b48 items=0 ppid=1 pid=4936 auid=500 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) comm="rpc.yppasswdd" exe="/usr/sbin/rpc.yppasswdd" subj=user_u:system_r:yppasswdd_t:s0 key=(null) An earlier attempt also had problems with another temp passwd file: Jun 27 15:25:52 lepton rpc.yppasswdd[2754]: Cannot create backup file /etc/shado w.OLD: File exists that one got an audit message of: type=AVC msg=audit(1182975952.065:145): avc: denied { unlink } for pid=2754 c omm="rpc.yppasswdd" name="shadow.OLD" dev=sda1 ino=1997849 scontext=system_u:sys tem_r:yppasswdd_t:s0 tcontext=system_u:object_r:etc_runtime_t:s0 tclass=file type=SYSCALL msg=audit(1182975952.065:145): arch=40000003 syscall=10 success=no exit=-13 a0=801f2050 a1=1 a2=80006428 a3=1 items=0 ppid=1 pid=2754 auid=42949672 95 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) comm="rpc. yppasswdd" exe="/usr/sbin/rpc.yppasswdd" subj=system_u:system_r:yppasswdd_t:s0 k ey=(null) Not sure why this error doesn't happen all the time.
Ok I will add the dac_override, but the /etc/shadow.OLD has the wrong context on it. It should be labeled shadow_t not etc_runtime_t. Did some init script create the file? Something other than yppasswd?
I'm really not sure about shadow.OLD, since it only threw that error once once and I couldn't duplicate it. A WHAG: I suspect it's a relic left around from something unrelated, perhaps running pwconv by hand long ago, which yppasswd (which presumably needs to run pwconv on its own to propagate its changes) collided with.
Fixed in selinux-policy-2.6.4-24
Is selinux-policy-2.6.4-24 the f7 version? My test system is fc6, running your first test version selinux-policy-2.4.6-75 from comment #1. Will be able to test it if it gets backported, but it'll be a while before my NIS servers get upgraded to the bleeding edge (they're production machines).
Fixed in current release