Subject: kern/36751: rpcbind AF_LOCAL socket gets wrong permissions
To: None <,,>
From: Wolfgang Stukenbrock <>
List: netbsd-bugs
Date: 08/08/2007 08:15:00
>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
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
Architecture: i386
Machine: i386
        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.
	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
        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.