hessmann@unipas.fmi.uni-passau.de (Georg Hessmann) (01/14/90)
Two processes communicate with the help of a socket. (Socket has the type PF_INET, SOCK_STREAM) The first process runs as a background demon (using inetd) and waits for incoming messages from the second process. Problem: How can the first process obtain the UID and GID of the second process right from the socket without any extra message from the second process. We want to disable/enable services of process one for certain UID's and GID's without changing the source code of the second process. Thanks, Georg. -- hessmann@unipas.fmi.uni-passau.de hessmann@unipas.uucp
jik@athena.mit.edu (Jonathan I. Kamens) (01/15/90)
In article <832@unipas.fmi.uni-passau.de>, hessmann@unipas.fmi.uni-passau.de (Georg Hessmann) writes: > [How can a program at one end of an Internet socket find out what the UID and > GID of the process at the other end of the socket are?] (I speak from experience with BSD4.3; I don't know if what I say below is wrong for other versions of Unix, although I very much doubt that it is.) This can't be done. An Internet domain socket doesn't have any UID or GID information associated with it; Internet domain sockets are not in any way tied to the Unix operating system -- tcp/ip code, including code to use sockets as Unix does, exists for any number of different architectures, including VM/CMS, VMS, and MacOS. You are going to have to send the UID and GID over the socket yourself at some point. Jonathan Kamens USnail: MIT Project Athena 11 Ashford Terrace jik@Athena.MIT.EDU Allston, MA 02134 Office: 617-253-8495 Home: 617-782-0710
lm@snafu.Sun.COM (Larry McVoy) (01/16/90)
In article <832@unipas.fmi.uni-passau.de> hessmann@unipas.fmi.uni-passau.de (Georg Hessmann) writes: >Two processes communicate with the help of a socket. >(Socket has the type PF_INET, SOCK_STREAM) >The first process runs as a background demon (using inetd) and waits >for incoming messages from the second process. > >Problem: >How can the first process obtain the UID and GID of the second process >right from the socket without any extra message from the second process. > >We want to disable/enable services of process one for certain >UID's and GID's without changing the source code of the second process. Well, this is a bummer. You can do it if really have to, but it requires that (1) both sockets must be on the same machine, and (2) having an indepth knowledge that machine's socket implementation. If you have both of those, the inetd-like process could open /dev/kmem and grovel around, looking for the socket that was sending, and figure out to whom it belonged (I think). You don't want to try this at home, campers, so the real answer is: "you can't." --- What I say is my opinion. I am not paid to speak for Sun, I'm paid to hack. Besides, I frequently read news when I'n drjhgungh, err, um, drunk.
brnstnd@stealth.acf.nyu.edu (01/17/90)
In article <1990Jan15.053647.24388@athena.mit.edu> jik@athena.mit.edu (Jonathan I. Kamens) writes: > In article <832@unipas.fmi.uni-passau.de>, hessmann@unipas.fmi.uni-passau.de > (Georg Hessmann) writes: > [ How can a program at one end of an Internet socket find out what the ] > [ UID and GID of the process at the other end of the socket are? ] You could use an RFC 931 Authentication Server implementation, so that you can find out the username by asking TCP port 113 on the client machine. My implementation is undergoing gamma testing. Unfortunately, it's easy to compromise security below TCP, so if you really want to know who you're talking to, run Kerberos. > This can't be done. An Internet domain socket doesn't have any UID or GID > information associated with it; It should. The Internet inherited that administrative flaw from the Arpanet. ---Dan
jik@athena.mit.edu (Jonathan I. Kamens) (01/18/90)
In article <20784@stealth.acf.nyu.edu>, brnstnd@stealth.acf.nyu.edu writes: > In article <1990Jan15.053647.24388@athena.mit.edu> jik@athena.mit.edu > (Jonathan I. Kamens) writes: > > This can't be done. An Internet domain socket doesn't have any UID or GID > > information associated with it; > > It should. The Internet inherited that administrative flaw from the Arpanet. Not convinced. The problem with assigning a UID and GID to a network socket is that not all machines connected to the network have a concept of UID's and GID's. It's quite common nowadays to see IBM PC's or Macs connected to an ethernet and given a network address; what UID and GID should be associated with socket connections to those machines. No, I would tend to agree with the decision not to associate UID and GID with a socket, simply because a UID's and GID's are Unix things, and the Internet is certainly not restricted to Unix machines. Jonathan Kamens USnail: MIT Project Athena 11 Ashford Terrace jik@Athena.MIT.EDU Allston, MA 02134 Office: 617-253-8495 Home: 617-782-0710
barmar@think.com (Barry Margolin) (01/18/90)
I've redirected followups to comp.protocols.tcp-ip, since this discussion is no longer Unix-specific. In article <20784@stealth.acf.nyu.edu> brnstnd@stealth.acf.nyu.edu (Dan Bernstein) writes: >In article <1990Jan15.053647.24388@athena.mit.edu> jik@athena.mit.edu (Jonathan I. Kamens) writes: >> This can't be done. An Internet domain socket doesn't have any UID or GID >> information associated with it; >It should. The Internet inherited that administrative flaw from the Arpanet. No, it shouldn't. UID's and GID's are inherently OS-specific; some systems use numbers, some use character strings, and some may use arbitrarily complex data structures. Additionally, some protocols are not used between user processes, but between systems in general (what UID should be associated with ICMP datagrams? what's the UID on a terminal concentrator?). The primary purpose of transport protocols such as TCP is to make a single physical link appear to be multiple links (i.e. multiplexing). Since simple links don't pass user identity along, multiplexed links don't need to, either. Application protocols should be independent of the mechanism used to establish the link; if they need to know user identities, then they'll need to pass it themselves when used over simple links, so it would be redundant to have the multiplexing protocol pass it as well. -- Barry Margolin, Thinking Machines Corp. barmar@think.com {uunet,harvard}!think!barmar