From owner-freebsd-hackers  Wed Jan  1 23:13:04 1997
Return-Path: <owner-hackers>
Received: (from root@localhost)
          by freefall.freebsd.org (8.8.4/8.8.4) id XAA20360
          for hackers-outgoing; Wed, 1 Jan 1997 23:13:04 -0800 (PST)
Received: from skynet.ctr.columbia.edu (skynet.ctr.columbia.edu [128.59.64.70])
          by freefall.freebsd.org (8.8.4/8.8.4) with SMTP id XAA20351
          for <hackers@freebsd.org>; Wed, 1 Jan 1997 23:12:57 -0800 (PST)
Received: (from wpaul@localhost) by skynet.ctr.columbia.edu (8.6.12/8.6.9) id CAA09967; Thu, 2 Jan 1997 02:10:23 -0500
From: Bill Paul <wpaul@skynet.ctr.columbia.edu>
Message-Id: <199701020710.CAA09967@skynet.ctr.columbia.edu>
Subject: Re: struct file locking
To: proff@iq.org (Julian Assange)
Date: Thu, 2 Jan 1997 02:10:22 -0500 (EST)
Cc: hackers@freebsd.org
In-Reply-To: <199701012224.JAA06593@profane.iq.org> from "Julian Assange" at Jan 2, 97 09:24:38 am
X-Mailer: ELM [version 2.4 PL24]
Content-Type: text
Sender: owner-hackers@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk

Of all the gin joints in all the towns in all the world, Julian Assange 
had to walk into mine and say:

> I am expanding the inet/socket code to permit firewall entries
> based on uid/gid. I have an aesthetic issue and one locking
> issue.
> 
> I need to pass socket credential information into ip_output.  There
> are two ways of doing this. I can add a back-pointer to the socket
> structure from the struct ipoption mbuf, or I can add an extra
> parameter to ip_output. I am inclinded towards the first option,
> for source-level compatability reasons.
> 
> In the socket structure I intend to create a back-pointer to
> originating struct file's->u_cred. What do I need to do to insure
> these last two structures are reliably locked and in memory?
> 
> Cheers,
> Julian.

I have a question.

Say you have the following series of events:

- A process creates a socket.
  o You now have a struct socket.
  o You also have a struct file that references the socket, and that
    points to the ucred of the process.

- The process forks.
  o Now the child and the parent refer to the same socket.

- The child does a setuid() to some other UID.
  o You still only have one socket.

What happens now? You have one socket referenced by two proccesses
with different credentials (I think -- not sure what happens to the
credentials in inherited descriptors when a process does a setuid()). 
This is kind of an odd situation; you probably don't want both processes 
reading or writing to the same socket, but in theory they could, so
you need to account for this somehow.

Assuming you can get at both sets of credentials, how do you know which
ones to use?

-Bill

-- 
=============================================================================
-Bill Paul            (212) 854-6020 | System Manager, Master of Unix-Fu
Work:         wpaul@ctr.columbia.edu | Center for Telecommunications Research
Home:  wpaul@skynet.ctr.columbia.edu | Columbia University, New York City
=============================================================================
 "It is not I who am crazy; it is I who am mad!" - Ren Hoek, "Space Madness"
=============================================================================