Xref: utzoo comp.sys.att:8472 unix-pc.general:4507
Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!uwm.edu!cs.utexas.edu!uunet!portal!cup.portal.com!thad
From: thad@cup.portal.com (Thad P Floryan)
Newsgroups: comp.sys.att,unix-pc.general
Subject: Re: Uniquely identifying a user: is it possible?
Message-ID: <25932@cup.portal.com>
Date: 14 Jan 90 13:19:12 GMT
References: <25730@cup.portal.com> <1143@utoday.UUCP>
  <25845@cup.portal.com>
Organization: The Portal System (TM)
Lines: 86

karl@MorningStar.Com (Karl Fox) in <KARL.90Jan13104731@crappie.MorningStar.Com>
writes:

	My UNIX-PC (3.51+Development) *does* have getpgrp(). I tried this quick
	hack and haven't been able to make it fail yet.  It works while su'd,
	nohup'ed and totally redirected.

Believe it or not, I did an almost identical program just minutes after
Scott S. Bertilson mentioned the getpgrp().  The docs for getpgrp(2) didn't
really give any hints as to how it'd be used, but INTRO(2) said the process
group ID is the PID of the "group leader", and examination of a "ps -ef"
output showed the relationship.

The { getpgrp() ... getutent() } strategy "almost" works:

	1. logging in on console (window), all cases work,
	2. logging in through /dev/ph0, all cases work,
	3. logging in through /dev/tty???, all cases work, but
 ===>	4. logging in through StarLAN, -=<NO>=- cases work.  Sigh.  :-(

The "problem" is that /etc/utmp doesn't contain any entry(ies) for a StarLAN
"listener" process.  Doing a "who -a" shows there's no process ID in /etc/utmp
matching what's shown by "ps -ef".

My approach to solving a problem is exemplified by a recent quote posted to
comp.mail.uucp by Erik Naggum (enag@ifi.uio.no):

	``  "get things _right_", not "get things _working_".
	    "Working" is a subset of "right."  ''

At this point, I've started looking at the proc structure <sys/proc.h> and at
the user structure <sys/user.h>, and have so far coded what's shown in the
fragment enclosure.  I need to look carefully at what this new program will do
since I have the distinct impression it's possible a process' entry could
disappear out from under me while reading /dev/kmem.

If anyone has suggestions how to handle THAT problem (browsing dynamically
changing structures), advice would be appreciated; the "ps" program must do
it, but I don't have sources.

Thad

-------------------- program fragment
#include <stdio.h>
#include <sys/types.h>
#include <sys/proc.h>
#include <sys/user.h>
#include <fcntl.h>
#include <nlist.h>

struct nlist adrget[3] = {
	{ "proc" },		/* info for sys/proc.h */
	{ "u" },		/* info for sys/user.h */
	{ NULL }
};

main(argc, argv)
	int	argc;
	char	*argv[];
{
	void	perror();
	int	close(), fprintf(), getpgrp(), nlist(), open();
	long	lseek();

	int	kmemfd;

	register int pgrp    = getpgrp();
	register int results = nlist("/unix", adrget);

	if (results < 0 || adrget[0].n_value == 0 || adrget[1].n_value == 0) {
		fprintf(stderr, "%s: namelist error for /unix\n", argv[0]);
		exit(1);
	}
	if ((kmemfd = open("/dev/kmem", O_RDONLY)) == -1) {
		perror("/dev/kmem");
		exit(1);
	}
	if (lseek(kmemfd, adrget[0].n_value, 0) < 0) {
		perror("lseek /dev/kmem");
		exit(1);
	}

/*	program "guts" to be inserted here	*/

	close(kmemfd);
}