>Number:         36750
>Category:       bin
>Synopsis:       rpcbind AF_LOCAL socket gets wrong permissions
>Confidential:   no
>Severity:       serious
>Priority:       high
>Responsible:    bin-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Wed Aug 08 08:10: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 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.
>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: