>Number: 36751
>Category: kern
>Synopsis: rpcbind AF_LOCAL socket gets wrong permissions
>Confidential: no
>Severity: serious
>Priority: high
>Responsible: kern-bug-people
>State: open
>Class: sw-bug
>Submitter-Id: net
>Arrival-Date: Wed Aug 08 08:15:00 +0000 2007
>Originator: Wolfgang Stukenbrock
>Release: NetBSD 3.1
>Organization:
Dr. Nagler & Comapny GmbH
>Environment:
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
Architecture: i386
Machine: i386
>Description:
This bug report has been original directed to "bin" as bin/36750.
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.
>How-To-Repeat:
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.
>Fix:
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
other protocols.
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.
>Unformatted:
|