Bug 242179 - rpc.ypasswdd not allowed to bind to privileged port
rpc.ypasswdd not allowed to bind to privileged port
Product: Fedora
Classification: Fedora
Component: selinux-policy-targeted (Show other bugs)
All Linux
low Severity low
: ---
: ---
Assigned To: Daniel Walsh
Ben Levenson
: Reopened
Depends On:
  Show dependency treegraph
Reported: 2007-06-01 19:58 EDT by Habig, Alec
Modified: 2007-11-30 17:12 EST (History)
0 users

See Also:
Fixed In Version: Current
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2007-08-22 10:12:05 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Habig, Alec 2007-06-01 19:58:05 EDT
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

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

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.
Comment 1 Daniel Walsh 2007-06-04 11:09:39 EDT
Fixed in selinux-policy-2.4.6-75
Comment 2 Habig, Alec 2007-06-14 10:45:59 EDT
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!
Comment 3 Daniel Walsh 2007-06-14 11:11:12 EDT
Having some infrastructure problems.  You can grab the packages from


I will try to push it to testing today.
Comment 4 Habig, Alec 2007-06-14 11:20:02 EDT
Great - I can confirm that this does fix it on my server, thanks!
Comment 5 Daniel Walsh 2007-06-14 11:51:40 EDT
Ok I got it pushed to fc6 testing.
Comment 6 Habig, Alec 2007-06-27 16:56:10 EDT
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 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

Not sure why this error doesn't happen all the time.
Comment 7 Daniel Walsh 2007-06-28 07:03:39 EDT
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?
Comment 8 Habig, Alec 2007-06-28 11:40:16 EDT
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.
Comment 9 Daniel Walsh 2007-07-01 20:29:50 EDT
Fixed in selinux-policy-2.6.4-24
Comment 10 Habig, Alec 2007-07-03 20:45:25 EDT
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).
Comment 11 Daniel Walsh 2007-08-22 10:12:05 EDT
Fixed in current release

Note You need to log in before you can comment on or make changes to this bug.