Subject: bin/36750: rpcbind AF_LOCAL socket gets wrong permissions
To: None <email@example.com, firstname.lastname@example.org>
From: Wolfgang Stukenbrock <Wolfgang.Stukenbrock@nagler-company.com>
Date: 08/08/2007 08:10:00
>Synopsis: rpcbind AF_LOCAL socket gets wrong permissions
>Arrival-Date: Wed Aug 08 08:10:00 +0000 2007
>Originator: Wolfgang Stukenbrock
>Release: NetBSD 3.1
Dr. Nagler & Comapny GmbH
System: NetBSD e010 3.1 NetBSD 3.1 (NSW-svc-ISDN) #20: Tue Aug 7 12:45:43 CEST 2007 wgstuken@e010:/usr/src/sys/arch/i386/compile/NSW-svc-ISDN i386
This bug report has been directed to "bin", but "kern" is also influenced!
There has happend a change in the bind code for AF_LOCAL sockets from
NetBSD 2.x to 3.1 (I've no 3.0 active anymore - perhaps the problem is
already in there.).
In "kern/uipc_usrreq.c" line 641 the mode bits are "now" masks
with the umask of the process:
"vattr.va_mode = ACCESSPERMS & ~(p->p_cwdi->cwdi_cmask);"
This will result in a socket mode of 755 for /var/run/rpcbind.sock
and no non-priviledged program can query rpcbind for information
via this socket due to missing write permissions.
On NetBSD 2.x the resulting mode gets 666 - I haven't found the location
(or searched for) where the x-bits gets removed from the mode in 2.x.
Run NetBSD 3.1 and start rpcbind (e.g. via /etc/rc.d/rpcbind start)
with different umasks. The system default (022) will lead to the
descripbed result above.
I'm not realy shure how to fix this in the right way.
First question is why the x-bits remains turned on on the
resulting socket. I think this is a bug and they should be turned
of in "kern/uipc_usrreq.c".
Then rpcbind need to set the umask to 0 prior calling bind on the
socket to allow access of the whole world to it. The bind() call
is in rpcbind.c line 301 - but there it is done for AF_LOCAL and
Netherless a "old_umask = umask(0);" in front of the bind() and
a "umaks(old_umask); behind it will solve this problem and the umask
should have no effect on othe protocols as far as I know.
Remark: I've no idea what other daemons may be affected too by the
change of the semantic in kern/uipc_usrreq.c.