NetBSD Problem Report #10798

Received: (qmail 25909 invoked from network); 9 Aug 2000 19:21:39 -0000
Message-Id: <200008091919.MAA06412@kronos.superscript.com>
Date: Wed, 9 Aug 2000 12:19:04 -0700 (PDT)
From: web-netbsd@superscript.com
Reply-To: web-netbsd@superscript.com
To: gnats-bugs@gnats.netbsd.org
Subject: getpeereid system call
X-Send-Pr-Version: 3.95

>Number:         10798
>Category:       kern
>Synopsis:       getpeereid system call
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    kern-bug-people
>State:          closed
>Class:          change-request
>Submitter-Id:   net
>Arrival-Date:   Wed Aug 09 19:22:01 +0000 2000
>Closed-Date:    Tue May 13 13:09:41 +0000 2008
>Last-Modified:  Tue May 13 13:09:41 +0000 2008
>Originator:     William E. Baxter
>Release:        1.4.2, NetBSD-current 10 August 2000
>Organization:
SuperScript

>Environment:

System: NetBSD kronos.superscript.com 1.4.2 NetBSD 1.4.2 (GENERIC) #7: Mon Aug 7 10:52:41 PDT 2000 root@kronos.superscript.com:/usr/src/sys/arch/i386/compile/GENERIC i386


>Description:
	A patch implementing a getpeereid() syscall in NetBSD
	is available at

	http://www.superscript.com/patches/netbsd-1-4-PATCH002.getpeereid

	This patch was originally generated and tested
	against netbsd-1.4.2, but evidently applies equally
	well to -current as of today.

	A local-domain server uses getpeereid() to obtain
	credentials from clients.  Credentials are passed
	when the client calls connect() and do not require
	that the client send any data.

	Based on getpeereid() I implemented ucspi-ipc, a framework
	for creating local-domain client/server programs.  This
	system allows a privileged server to act on behalf of
	nonprivileged clients without setuid programs.  Access
	to services is easily configurable based on information
	obtained via getpeereid.  Clients pass credentials at
	connect(), and therefore cannot consume connections
	anonymously.

	Links to background information, patches, and applications
	appear on the ucspi-ipc home page at

	http://www.superscript.com/ucspi-ipc/intro.html

	I would like to see getpeereid() or sufficient basis for
	it incorporated into future NetBSD releases so that we
	can all use ucspi-ipc without the need for a kernel patch.

>How-To-Repeat:

>Fix:

>Release-Note:
>Audit-Trail:

From: Jason R Thorpe <thorpej@zembu.com>
To: web-netbsd@superscript.com
Cc: gnats-bugs@gnats.netbsd.org, tech-kern@netbsd.org
Subject: Re: kern/10798: getpeereid system call
Date: Wed, 9 Aug 2000 12:58:04 -0700

 On Wed, Aug 09, 2000 at 12:19:04PM -0700, web-netbsd@superscript.com wrote:

  > >Synopsis:       getpeereid system call

  > 	A local-domain server uses getpeereid() to obtain
  > 	credentials from clients.  Credentials are passed
  > 	when the client calls connect() and do not require
  > 	that the client send any data.

 I implemented a different mechanism, the LOCAL_CREDS socket option,
 which is based on the BSD/OS method as described by Stevens, some
 time ago, and will appear in NetBSD 1.5.  NetBSD's libc/rpc library
 already uses it.

 LOCAL_CREDS, set by a server listening on a Unix domain socket,
 causes a "sockcreds" message (which includes the supplemental group
 list for the user, as well) to come in as ancillary data.  This
 happens for every datagram in the SOCK_DGRAM case, and upon the
 client's first send of data in the SOCK_STREAM case.

 It is not possible for the client to forge the credentials.

  > 	I would like to see getpeereid() or sufficient basis for
  > 	it incorporated into future NetBSD releases so that we
  > 	can all use ucspi-ipc without the need for a kernel patch.

 I suppose NetBSD *could* add getpeereid(), but we already have
 a (more flexible mechanism), and if ucspi-ipc were changed to
 use it, we still wouldn't need a kernel patch :-)

 -- 
         -- Jason R. Thorpe <thorpej@zembu.com>

From: "William E. Baxter" <web@superscript.com>
To: Jason R Thorpe <thorpej@zembu.com>, gnats-bugs@gnats.netbsd.org,
  tech-kern@netbsd.org
Cc:  
Subject: Re: kern/10798: getpeereid system call
Date: Wed, 9 Aug 2000 15:43:20 -0500

 On Wed, Aug 09, 2000 at 12:58:04PM -0700, Jason R Thorpe wrote:
 > On Wed, Aug 09, 2000 at 12:19:04PM -0700, web-netbsd@superscript.com wrote:
 > 
 >  > >Synopsis:       getpeereid system call
 > 
 > I implemented a different mechanism, the LOCAL_CREDS socket option,
 > 
 > LOCAL_CREDS, set by a server listening on a Unix domain socket,
 > causes a "sockcreds" message (which includes the supplemental group
 > list for the user, as well) to come in as ancillary data.  This
 > happens for every datagram in the SOCK_DGRAM case, and upon the
 > client's first send of data in the SOCK_STREAM case.

 I'd be happy to use LOCAL_CREDS if it permitted the server to obtain
 credentials without waiting for the client to provide them.
 Otherwise, clients can consume connections anonymously, and that's
 unacceptable for my application.

 If LOCAL_CREDS caused connect() to pass credentials immediately, in
 addition to the present behavior, that would almost suffice.  There
 would need to be a means to access the information on the server side.

 Regards,
 W.
State-Changed-From-To: open->closed
State-Changed-By: ad@NetBSD.org
State-Changed-When: Tue, 13 May 2008 13:09:41 +0000
State-Changed-Why:
We have this call now.


>Unformatted:

Home	PR Database Search