[unix-pc.general] Who is "logged in" when you are running multiple login windows?

dave@galaxia.Newport.RI.US (David H. Brierley) (03/18/90)

Here is a problem I am currently attempting to solve.  I am hoping that
someone on the net might be able to come up with some kind of inspired
solution for it, or at least point me in the right direction.

I am working on a replacement for the window manager and the status
manager.  This program will include all the features of the 3.51 wmgr and
smgr programs, with the exception of cron functions, and will also include
some of the features of the "hotkey" program that I released a while ago
and some features of the replacement wmgr program that was posted.  One of
the features of the replacement wmgr that I have included is the ability to
create multiple login windows on the console.  The "hotkey" capability
allows each user to define a command that is to be run when one of the
shifted function keys is pressed.

The problem I am having is that if there is more than one user logged in on
the console, which one is the "currently active user".  When one of the
shifted function keys is pressed I want the program to do a setuid() to the
currently active user before running the command since otherwise all the
commands would run as root.  I also need to know who the current user is in
case the user asks to read his mail.  My first thought was to scan through
the utmp file to see who is logged in and then look at each of the window
devices to see which one was accessed most recently and therefore determine
which user most recently typed something on the keyboard.  This seemed to
work ok until my wife logged in and started up the UA, at which point it
stopped working.  It seems that the UA doesn't bother to change the
ownership of the window devices, in fact it cannot change the owner because
it is not running as root.  As soon as my wife allocated a window which was
previously owned by me, my program began insisting that I was the currently
active user instead of my wife.

If anyone has any ideas on how to solve this problem it would be greatly
appreciated.
-- 
David H. Brierley
Home: dave@galaxia.Newport.RI.US   {rayssd,xanth,lazlo,mirror,att}!galaxia!dave
Work: dhb@rayssd.ray.com           {sun,uunet,gatech,necntc,ukma}!rayssd!dhb

bdb@becker.UUCP (Bruce Becker) (03/19/90)

In article <871@galaxia.Newport.RI.US> dave@galaxia.Newport.RI.US (David H. Brierley) writes:
|
|I am working on a replacement for the window manager and the status
|manager.  This program will include all the features of the 3.51 wmgr and
|smgr programs, with the exception of cron functions, and will also include
|some of the features of the "hotkey" program that I released a while ago
|and some features of the replacement wmgr program that was posted.  One of
|the features of the replacement wmgr that I have included is the ability to
|create multiple login windows on the console.  The "hotkey" capability
|allows each user to define a command that is to be run when one of the
|shifted function keys is pressed.

	I'm confused about why there's a problem.
	I run 4 login windows on the console all
	the time under wmgr.  I just added more
	entries to /etc/inittab (vi2, vi3, vi4)
	so that each getty gets a separate window.
	Shift-suspend & shift-resume move back &
	forth between them.

	The first window in the list (when one
	clicks on the "W" icon in the top right
	corner of the screen) owns the mail, phone,
	calendar, etc...

	I have a question of my own - can one allocate
	more than 12 windows in the new kernel? I've
	tried all sorts of stuff in 3.51 but nothing
	above /dev/w12 ever gets activated...

Cheers,
-- 
  (__)	 Bruce Becker	Toronto, Ontario
w \@@/	 Internet: bdb@becker.UUCP, bruce@gpu.utcs.toronto.edu
 `/v/-e	 UUCP: ...!uunet!mnetor!becker!bdb
_/  \_	 "So far from God, so close to the United States" - Old Mexican proverb

andy@jhunix.HCF.JHU.EDU (Andy S Poling) (03/19/90)

In article <871@galaxia.Newport.RI.US> dave@galaxia.Newport.RI.US (David H. Brierley) writes:
[...]
>The problem I am having is that if there is more than one user logged in on
>the console, which one is the "currently active user".  When one of the
>shifted function keys is pressed I want the program to do a setuid() to the
>currently active user before running the command since otherwise all the
>commands would run as root.  I also need to know who the current user is in
>case the user asks to read his mail.  My first thought was to scan through
>the utmp file to see who is logged in and then look at each of the window
>devices to see which one was accessed most recently and therefore determine
>which user most recently typed something on the keyboard.  This seemed to
>work ok until my wife logged in and started up the UA, at which point it
>stopped working.  It seems that the UA doesn't bother to change the
>ownership of the window devices, in fact it cannot change the owner because
>it is not running as root.  As soon as my wife allocated a window which was
>previously owned by me, my program began insisting that I was the currently
>active user instead of my wife.
>
>If anyone has any ideas on how to solve this problem it would be greatly
>appreciated.

Ahhh.  I ran into this problem when I too replaced smgr and wmgr with my own
home-brew manager.  In my setup, I implemented faster UA-type widowed menus
and I needed to know who was mousing my manager (out of multiple concurrent
windows).  Since everything is in one program in my case, I simply kept
track of the last non-root window that was active (since I made it active, I
know).  When the menu functions are moused, I use that stored uid.  This,
effectively, does the same thing as checking utmp, then tty ownership.  I
don't run the UA anymore so I don't know if my scheme works any better with
it.  However (and this is a reasonably big however :-) since my manager also
logs people in, it routinely (every 2 secs) checks whether any closed
windows are improprly represented in utmp and changes the utmp entries for
those windows to reflect a logout.  I think this would make that troublesome
UA window "invisible" since utmp would show it as "logged out".  I consider
this proper behavior on the part of my software - to act otherwise would
throw security out the window.

The real problem is that the UA was intended for a single user environment.

-Andy

--
Andy Poling                              Internet: andy@gollum.hcf.jhu.edu
Network Services Group                   Bitnet: ANDY@JHUVMS
Homewood Academic Computing              Voice: (301)338-8096    
Johns Hopkins University                 UUCP: mimsy!aplcen!jhunix!gollum!andy

rlw@ttardis.UUCP (Ron Wilson) (03/20/90)

In article <4518@jhunix.HCF.JHU.EDU>, andy@jhunix.HCF.JHU.EDU (Andy S Poling) writes:
>effectively, does the same thing as checking utmp, then tty ownership.  I
>don't run the UA anymore so I don't know if my scheme works any better with
>it.  However (and this is a reasonably big however :-) since my manager also
>logs people in, it routinely (every 2 secs) checks whether any closed
>windows are improprly represented in utmp and changes the utmp entries for
>those windows to reflect a logout.  I think this would make that troublesome
>UA window "invisible" since utmp would show it as "logged out".

What troublesome UA window?

> I consider
>this proper behavior on the part of my software - to act otherwise would
>throw security out the window.

Your window manager sounds a "little" busy - I mean why do you need to constant-
ly rework the utmp file?  When a window is allocated (by open("/dev/window",...)
), update the utmp entry, and then the same when the window is deallocated (by
the final close).

BTW: the utmp file is not intended (nor used by the kernal) for security
purposes - it is an informational file maintained by getty and login - I
know from experience that a messed up utmp doesn't hurt system security -
any program that relies on utmp to be correct should be rewritten - the ONLY
use I make of the utmp/wtmp info is for connect time statistics.

>The real problem is that the UA was intended for a single user environment.

The UA works quite well in a multi user environment - many of my users DO
use it (ttardis is a BBS) - my only complaint is that there appears to be
no way to get it to accept \r (ASCII 13 deciaml - carraige return) as ENTER -
not all of ttardis's users have terminals with line feed keys, and, unfortu-
nately, I know the physical keyboard layouts to be able to assign function
keys appropriately.  Also, if anybody knows a way to specify what the the
screen labeled function keys do in UA - I would like that too.

- Ron Wilson
rlw@ttardis
rel.mi.org!ttardis!rlw
sharkey!cfctech!ttardis!rlw
uunet!edsews!rel!ttardis!rlw

andy@jhunix.HCF.JHU.EDU (Andy S Poling) (03/21/90)

In article <2507@ttardis.UUCP> rlw@ttardis.UUCP (Ron Wilson) writes:
>In article <4518@jhunix.HCF.JHU.EDU>, andy@jhunix.HCF.JHU.EDU (Andy S Poling) writes:
>>However (and this is a reasonably big however :-) since my manager also
>>logs people in, it routinely (every 2 secs) checks whether any closed
>>windows are improprly represented in utmp and changes the utmp entries for
>>those windows to reflect a logout.  I think this would make that troublesome
>>UA window "invisible" since utmp would show it as "logged out".
>
>What troublesome UA window?

The one that doesn't have anyone logged in on it.  IMHO, since a window looks
like a tty, if it is active someone should be logged in on it.

>> I consider
>>this proper behavior on the part of my software - to act otherwise would
>>throw security out the window.
>
>Your window manager sounds a "little" busy - I mean why do you need to constant-
>ly rework the utmp file?  When a window is allocated (by open("/dev/window",...)
>), update the utmp entry, and then the same when the window is deallocated (by
>the final close).

Because I run alot of processes (occasionally filling the process table), I
consider having getty (or an equivalent) hanging around waiting for someone
to logout a waste of a process slot.  Since the window driver is kind enough
to take care of closing the window for me, all I have to do is notice when
it does.


>any program that relies on utmp to be correct should be rewritten

I humbly await your new version of who(1) which doesn't use the utmp file.

-Andy

ostroff@Oswego.EDU (Boyd Ostroff) (03/22/90)

I'm still a little confused over the original problem here, but I've
also had problems telling who the user is when running multiple windows
on the system console.  (Note: I've been using a very simple UA replacement
which provides multiple 24x80 console windows in a small font for over a 
year without problems - it's called "wlogin" and I posted it some time ago -
write if interested).

Anyway, I wrote this little function to use as a getlogin() replacement and
include it here since it might be of use to someone.  It just finds out
your tty name then reads through the utmp file until it finds a matching
entry.

||| Boyd Ostroff - Tech Director - Dept of Theatre - SUNY Oswego 
||| Sys Admin - "The CallBoard" - (315) 947-6414 - 1200/2400 baud 
||| ostroff@oswego.oswego.edu - cboard!ostroff@oswego.oswego.edu 

------------------------- cut here ---------------------------
#include <sys/types.h>
#include <utmp.h>
#include <time.h>
#include <stdio.h>
#include <pwd.h>
#include <string.h>


char *get_login()           /* added this function to replace getlogin() */
{                           /* which doesn't work properly with multiple */
struct utmp *getutent();    /* windows on the Unix-PC system console */
struct utmp *u;             /* Boyd Ostroff (ostroff@oswego.oswego.edu) */
char *ttyname();
char *where;

    where = 1 + strrchr(ttyname(0), '/');
    setutent();
    while ((u = getutent()) != NULL)
        {
        if (u->ut_type == 7) 
            {
            if (strcmp(where, u->ut_line) ==0)
                {
                 return(u->ut_user);
                }
            }
        }
    endutent();
}