From owner-freebsd-net@FreeBSD.ORG Wed Mar 9 00:13:34 2005 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6ED6B16A4CE for ; Wed, 9 Mar 2005 00:13:34 +0000 (GMT) Received: from rosebud.otenet.gr (rosebud.otenet.gr [195.170.0.26]) by mx1.FreeBSD.org (Postfix) with ESMTP id D68B843D1D for ; Wed, 9 Mar 2005 00:13:32 +0000 (GMT) (envelope-from keramida@ceid.upatras.gr) Received: from gothmog.gr (patr530-a164.otenet.gr [212.205.215.164]) j290DBoj012432; Wed, 9 Mar 2005 02:13:11 +0200 Received: from gothmog.gr (gothmog [127.0.0.1]) by gothmog.gr (8.13.3/8.13.3) with ESMTP id j290DPJN005537; Wed, 9 Mar 2005 02:13:25 +0200 (EET) (envelope-from keramida@ceid.upatras.gr) Received: (from giorgos@localhost) by gothmog.gr (8.13.3/8.13.3/Submit) id j290DO1Y005536; Wed, 9 Mar 2005 02:13:24 +0200 (EET) (envelope-from keramida@ceid.upatras.gr) Date: Wed, 9 Mar 2005 02:13:24 +0200 From: Giorgos Keramidas To: Andreas Bachmann Message-ID: <20050309001324.GF5173@gothmog.gr> References: <1110107067.2060.26.camel@notebook.bachi.net> <20050306113602.GA72592@gothmog.gr> <1110110710.2060.48.camel@notebook.bachi.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1110110710.2060.48.camel@notebook.bachi.net> cc: freebsd-net@freebsd.org Subject: Re: static pid and uid for a socket? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Mar 2005 00:13:34 -0000 On 2005-03-06 13:05, Andreas Bachmann wrote: > > AFAIK, this can only be done if the original process calls execve() on a > > setuid binary and has not marked the socket descriptor as close-on-exec. > > i'm developing a gtk+ based equivalent to 'sockstat'. > when a user is proposed to run a process, which creates a socket, the > sockstat printout is for example: > > USER COMMAND LOCAL ADDRESS FOREIGN ADDRESS > myuser myprog 10.0.0.10:52265 66.102.11.99:123 > > but, can the displayed kernel socket structure abrupty (by fork() or > setuid()) change user or process (because xfile.xf_uid or xfile.xf_pid > changed)? No. At least, not by a fork() that creates a new process. Each process has a (struct filedesc) in its proc structure. The filedesc holds information about all the open file descriptors of the process. The filedesc is an interface for the list of open (struct file) objects that a process holds. A somewhat simplified ASCII-art view is: struct proc +--------------------+ | | | struct filedesc | | +--------------+ | | | X---------------> struct file | | | | +------------+ | | | | | | | +--------------+ | | f_cred --------> struct ucred +--------------------+ | | +----------+ +------------+ | | +----------+ When a new process is created, its filedesc is copied from the filedesc of the parent process. The file descriptors of the parent process are copied [1]. The copying points to the very same (struct file) objects, so initially the credentials (owner) of the open files in the child are set to the same as those of the parent process. The parent and child share through their filedesc structures the same (struct file) object so far. This is not a problem, since they obviously have the same credentials anyway. When one of the processes that share open file objects in this way calls execve() (or one of its wrappers), the file decriptors are explicitly "unshared" to avoid security violations [2]. As far as I can tell, the owner of the (struct file *) object is not used(?), because the file operations accept a ucred pointer and use that for access checks to the underlying object (vnode, socket, etc). Since I'm only beginning to learn about the way file descriptors work in FreeBSD, someone who knows the internals better may put it in better words :-) [1] See revision 1.249 of kern_fork.c, near lines 416-418. [2] See revision 1.266 of kern_exec.c near lines 461-465.