Guest account happenings

May 3 23:44 UTC 1995

  The first cut at a guest account, as discussed in oldcoop item 86, is
ready for testing.  It still has a password, and only supports one user
at a time, but the menus and intro screens are set up.  If you have any
ideas on user interface, wording, security/efficiency improvements, or
whatever, please post them!
 
  If you want to run just the basic menu, type !/u/guestadm/guest_menu.
("Quit" won't really disconnect you from Grex).  If you want to try out
the account, log in as user guest, password xyzpdq.  If you want to be a
nuisance, change guest's password to something else.  (Please don't :-)
 
  By the way, the guest account has consistently been getting around
five bad login attempts per day, so even without listing it in the login
help screen, it looks like it would see some use.
 
-----
 
Menus
 
  Here's the basic idea: the guest account uses as its shell a script
called /u/guestadm/guest_login.  This sets the environment variables,
erases all the files in /u/guest, recopies the few that are needed (to
prevent tampering), resets guest's mail spool, then starts a guest menu:
 
  Guest Menu
    1. Info about Grex
    2. Try out the most popular activities on Grex
    3. Go to the comprehensive menu (not this guest menu)
    4. Create your own account
    5. Quit (disconnect from Grex)
  Choice?
 
  Choice 1 gives an "info menu" of basic questions about Grex, with each
choice giving a screen of text (72x24 characters), then returning to the
info menu.
 
  Choice 2 gives a similar menu, with options to describe party,
Picospan, and mail, and options to actually start party and Picospan. If
the user starts Picospan, it asks for a name to use, or to press return
to remain anonymous, then puts the name or "Guest User" in a .cfrc file.
The name will be used if the guest user decides to respond to anything.
For both Picospan and party, before the programs are started, the user is
encouraged to get their own account if they decide to hang out here for
long.
 
  Choice 3 runs Dave Parks' menu program, with a note saying type E to
get back to the guest menu.  I was thinking of making a copy of this to
add some guest-specific notes before it ran conferences, party, or mail,
but then maintenance to the DP menu would require changes in both copies.
 
  Choice 4 does an "exec login newuser," which runs the newuser program.
 
  Choice 5 does an "exit," which logs guest out, since the menu is guest's
login shell.  If you ran it from another account, it just exits the menu.
 
  Guests can can also run other unix commands by typing !command.  If
they start a unix shell like sh or csh, then run conf/bbs, party, or
mail/pine/elm, a small script is run first (in /u/guestadm/aliases) to
give the user similar info to what they would have gotten by running
these from the activities menu, before actually running the programs.
 
-----
 
  The guest acct's Picospan prompt listed below is similar to the default
for new users, but is spaced a bit more vertically.  I would have used a
two-column format, with a couple more commands, but the prompt is limited
to 255 characters, and this is at the max.  Any suggestions?
 
  Commands:
   browse      Shows list of numbered items
   read #      Shows an item, e.g. read 15
   help conf   Lists other conferences
   join <name> Change conferences, e.g. join music
   help        Lists commands
   quit        Exits
  Ok:
 
-----
 
Known things remaining to be done:
 
  1) Eliminate the password for the account, make sure guest can't
     change passwords, and make sure the password program won't request
     annual password changes.
 
  2) Prevent the guest user from sending mail, at least off-site.
     General idea: let them run mail programs, but have outgoing mail
     intercepted and erased, and let guest users know that's what will
     happen.
 
  3) Keep individual Picospan files for each guest users for the
     duration of their call.  (Participation files are erased on login,
     and a new .cfrc is created when the guest user starts Picospan).
 
  4) Preclude the guest user from tinkering with jobs or files of
     other guest users (e.g. if both were logged in as 'guest').
 
  5) Mention "guest" in newuser's help screen; maybe change as follows:
 
     Old: newuser     To create your own login-id on Grex.
 
     New: newuser     To create your own login-id on Grex.  Usually
                      takes around 5 to 15 minutes.
 
          guest       To log in with the guest login-id, if you want
                      to check out Grex before creating your own login-id.
 
  6) Add an initial "foreign language branch," to switch to a translated
     version of the guest's menu and help screens (depends on finding
     volunteer translators :).

response 2 of 103:

May 4 06:35 UTC 1995

As I mentioned at the meeting, I think step #4 is doable by creating a
subdir under /home/guest with the user's PID. And then pointing their HOME
environment variable at that subdir.
OTOH, step #4 just is NOT possible. It's a guest account, there's only so
much you can do and expect.

Ajax suggested at the meeting that this be accomplished by creating 10
guest accounts called guest01 through guest09. Login would check to see
which guest account "slot" was available and log the user in as that
particualar guest. In theory this would work, HOWEVER, that would require
a *great* deal of work to be done on the login program itself. Right now,
I'd say there are only 2 people(maybe 3) qualified to work on the login
program and none of us has the time to do development of this scale.

response 4 of 103:

May 4 09:57 UTC 1995

I'll go over the wording with a fine tooth comma when I'm more awake
but in general this looks terrific.  Thanks a bunch Rob!

I've been doing some thinking about how to handle multiple simultaneous
guest logins in such a way that login wouldn't have to be modified.
If and when I've convinced myself that my ideas aren't complete
hogwash, I'll share 'em in mail with relevant people.

response 6 of 103:

May 5 03:53 UTC 1995

"fine tooth comma," heh...

Re #2:  Do you have a good idea for step #4, or is it not possible; would
  you make up your mind?  :-)
  Also, correct me if I'm wrong, but guest01 through guest09 is only 9 guest
  accounts...

Re #0: 
1) Have part of the reset or exit script be to reset the PW to "guest".
2) If the mail programs are compiled here, alter the source, and recompile,
  with the calls to mail progs being redirected to the modified files.
3&4) Would seem to be amenable to the sol'n of having multible actual accts.
5) Obviously just take a few minutes of staff time.
6) Good luck !!  *grin*

response 8 of 103:

May 5 07:36 UTC 1995

I stand behind what I said in reponse #2. Even if there is a way to make
something work in *theory*, but nobody has the time to implement it, ot
the theoretical solution is just too damn complex, then for all practical
purposes, it is not possible.

response 10 of 103:

May 5 10:50 UTC 1995

Oh, yes.  Greg, would it really be necessary to modify login to allow
(say) users guest01-guest09?  I'd suggest having an exec login call in
the .login file for guest, or something like that.  Wouldn't that work?
If it would, it would be far preferable to customizing login.  (I would
worry about simultaneous logins, though; I really prefer setting up temp
dirs based on PID.)

response 12 of 103:

May 6 15:04 UTC 1995

Re #1, I thought about adding the lynx shell, but my feeling is that it
       adds a bit of complexity, because (1) it requires a correct term
       setting, and (2) it seems more complex than 'menu' for simple system
       navigation. As it is, it can be reached by going from the guest menu
       to the Dave Parks menu, though that's pretty indirect. If people
       think it should be added, then I'd suggest changing the main guest
       menu option from "3. Go to the comprehensive menu (not this guest
       menu)" to "3. Try out Grex's full menus (not this guest menu)," and
       then have that option pull up another menu with "1. Describe 'menu',
       2. Run 'menu', 3. Describe Lynx, 4. Run Lynx, 5. Return to main
       menu." Please voice any opinions y'all have on this!
 
Re #2 & the difficulty in modifying login, it seems pretty easy, like:
           if name == "guest" then
               num = '0'
               while (num <= '9') and is_logged_in("guest"+num) inc(num)
               if num <= '9' then name = "guest"+num
           endif
       and have the actual guest acct display "sorry, all guest accts in
       use", and log out.  It could also use a contention algorithm to
       avoid two guests getting the same id simultaneously, and if there's
       no ready-made "is_logged_in" function, that could take a bit, but
       it's not the biggest software project humankind has ever undertaken!
 
       On the other hand, doing the login switch from within a login
       script seems feasible...less efficient, but easier to maintain.
 
Re #3, a) I'll mail you the section describing Picospan to get more
       feeback.  I omitted a word by mistake, but it's still confusing.
 
       b) Both party and Picospan take a long time to start...the guest
       menu says "This may take a moment" warning before the programs;
       perhaps I should change it to "this may take *several* moments" :-).
       Valerie said that the uid, or position of an account in /etc/passwd,
       impacts the speed with which Picospan starts up; maybe the same is
       true with party.  People with old accounts have low uids, and
       Picospan pops right up.  Guest has a new account, so a minute or
       more delay isn't uncommon.  Maybe guest's uid could be lowered, to
       give it a speed boost, but that could give guests unrealistic
       expections of how fast Grex will be when they get their own
       accounts.
 
       c) "Terminal type problems.  How is the terminal emulation set up
       for that, anyway?"  It's currently set to type "ansi."  I was
       thinking there aren't any full-screen programs listed in basic guest
       menu, but I didn't know the "pico" editor was full-screen.  I
       suppose prompting the user for a term type is the best approach.
       Does anyone know if the terminal type from Internet connections is
       sometimes passed to the login program on Grex, and how it's passed?
 
       d) "When I quit the conferences, I was logged off...."  This hasn't
       happened to me, but I was disconnected when I hit some ctrl keys
       from Picospan.  Can you give it another try to see if it might have
       been an anomoly?
 
Re #4, I look forward to your word comma-ing!  I also thought up a way to
       switch accounts from a login script, but it's pretty kludgey, so I'd
       love to hear other ideas!
 
Re #6, (1) Rather than resetting the password on logout, it's probably
           cleaner to modify passwd to not record password changes for
           guest, or login to ignore passwords for guest (there won't be
           any guest password when it's ready for prime time).
 
       (2) I think sendmail can be modified, rather than modifying each
           mail program; it would do the same tlhing, but at a lower level.
 
Re #9, I agree; the control files are already owned by someone else -
       "guestadm."  Guest's shell is /u/guestadm/guest_login, which erases
       all the files in /u/guest, then recopies those that are needed back
       to /u/guest.  Not real efficient, but it works.
 
Re #10, I think that would work, and simultaneous logins could be avoided
       with a little work.  Why do you prefer temp dirs over separate
       logins?

response 14 of 103:

May 7 03:27 UTC 1995

Re #12: Greg answered your question for me (& much more knowledgeably &
completely than I could have).  It's still *conceivable* with a
PID-based system that PIDs could roll over and give you a new person
logging in as guest with a process that has the same PID as the one for
someone already logged in as guest ... but personally I'd take that
chance for the sake of avoiding locking code.  Out of 64K PIDs (I think
here as well as where I learned) minus a few that persist, what's the
chance of two simultaneous guests with the same ones for their login shells?

I'm also against anything that involves using up more UIDs, but that's very
minor in this case.  We're going to have to do something drastic for entirely
different reasons, very soon, I think.

response 16 of 103:

May 7 15:28 UTC 1995

Re 13: Rob discussed locking concerns in response #12.  And it's offensive
to call him a "Newbie-Programmer" -- he's been doing professional
programming for years and (not my opinion as his SO, but my professional
opinion) he's damn good at it.

Re 15: The question of guest accounts was discussed a while ago, and the
board voted to go forward with experimenting with them.  It's a bit late
to be saying not to do it.

response 18 of 103:

May 7 16:41 UTC 1995

I didn't imply Rob was a newbie programmer. I just said he made a newbie-
programmer mistake. *I* make newbie-programmer mistakes sometimes too. :-)
But he's right, I went and re-read his response and it seems I missed part
of what he said.

However, the issue of how you determine if a guest account slot is in use,
is still a difficult one. Also you have to come up with a fool-proof
way of clearing those slots too. If a mechanism exists for a guest user to
logoff/disconnect/terminate his session without removing the token for
that slot, you will eventually exhaust all the slots in this manner and no
guests will be able to get in until the slots are freed manually. This
becomes yet another thing staff has to watch.

To answer davel: Yes, you are right. We actually only have 32768 uids.
Er, I mean *pids*.. But the chance of them wrapping around and a new guest
user getting the same pid as that of one already logged in, is not only
very unlikely statistically, it's also impossible. The system won't assign
a pid if it's already in use. It will skip to the next available one.

Locking schemes are always hairy to program and are best avoided if at all
possible. Creating 10 guest accounts can't be implemented without a
locking scheme.

response 20 of 103:

May 8 01:52 UTC 1995

  Re 18, actually, I was thinking of a non-locking approach, using a kind
of "carrier-sense/collision detect" protocol: have guest's login script
check for an available guest# account, by making sure it's not in /etc/utmp
and has no processes running ("carrier sense").  Next, log in as that
user...in guest#'s login script (for example guest2's), check again that
nobody *else* is using guest2, based on the same criteria ("collision
detect").  If they're the only guest2 (normal case), no problem.  If another
guest2 is on (either logged in at the same time, or typed guest2 at login:),
then whoever has the lowest tty stays, and the other one goes through the
same process that the guest account initially went through to identify a
different guest# account to use.  If all guest accounts are busy, give a
message and log out (or run login, from which the user can run newuser -
though that could get messy).
 
  This algorithm makes some assumptions I'm not positive about (e.g. that
the login script can prevent users from breaking out as they're logging in,
Grex supports passwordless accounts, and the "account is busy" algorithm is
generally reliable), but it's pretty simple.  Aside from making accounts
passwordless, I could write it myself, without further staff assistance.
 
  Any thoughts on whether it would work, or suggested alternatives for
handling multiple guests?  Using one guest id with multiple temporary
directories is easy, but has some drawbacks: guests could fiddle with other
guests' files and processes, they'd have indistinguishable names in party,
they'd be able to echo text to other guests' ttys, it would be a bit harder
to "write" to a particular guest, and they'd share the same mail spool (it
has an intro message assigned to it when they log in).  None of those are
that important, but all seem undesirable.

response 22 of 103:

May 8 13:31 UTC 1995

  One flaw I thought of: tty won't work to decide who stays.  Probably
date/time of earliest process, with ties broken by lowest pid (accounting
for pid wraparound) would do it.
 
  Hm, several pages?  Do you think the basic approach is reasonable?  Would
a phone call work in place of the meeting, or do you want multiple inputs?

response 24 of 103:

May 9 06:28 UTC 1995

Thankxx ajax, this is a load of work for which i am thankful, as well
as learning a few newbie-programmer "tricks." Thought experiments are
wonderful excercises.
  
Would there be much problem/grief with the guest01, 02, 03 ... if
each such loginid had a separate filespace? One limiation would be
the total number of guest slots, but, gee, so what?
  
And, fwiw, could the passwds be the same as the loginid?
 
Thankxx also to mdw, gregc, davel, and others for tossing legitimate
and perceptive potshots. Defensive programming is necessary.
  
Also, supporting mdw's idea, a limitation on "what's available" is
pretty good.