Xref: utzoo unix-pc.general:5128 comp.sys.att:9151
Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!uwm.edu!cs.utexas.edu!tut.cis.ohio-state.edu!purdue!mentor.cc.purdue.edu!pur-ee!ea.ecn.purdue.edu!mccoy
From: mccoy@ea.ecn.purdue.edu (Chris A McCoy)
Newsgroups: unix-pc.general,comp.sys.att
Subject: Re: Perplexing ATE Failure for non-root users
Keywords: ATE unix-pc
Message-ID: <19820@ea.ecn.purdue.edu>
Date: 30 Mar 90 00:56:19 GMT
References: <19811@ea.ecn.purdue.edu>
Distribution: usa
Organization: Purdue University Engineering Computer Network
Lines: 43

In article <19811@ea.ecn.purdue.edu>, mccoy@ea.ecn.purdue.edu (Chris A McCoy) writes:
> 
> One of our users is experiencing a strange problem with his 3B1.
> The ATE fails and responds with the following message under two
> conditions:
> 
>                 Attempt failed when terminal emulator
>                 tried to set the group file access
>                 privilege to the login user's.
>			.
>			.
> 

Well, I think I've solved the problem.  I received many good suggestions,
but none solved the problem.  Most everyone wanted me to post the 
solution. It appears to be somewhat complicated, but here goes:

When a user runs "/usr/bin/async_main", either form UA or from the UNIX
shell, async_main checks /etc/utmp to find out who the user is.  After 
obtaining this information, it reads the corresponding passwd entry to
get the group id and then tries to perform a setgid.  If a user is logged 
onto the machine more than once, async_main gets confused when trying
to read /etc/utmp.  It may not even check return codes after reading
utmp.  Once confused, it can't determine who the user is, and thus, can't
read the passwd file correctly to set the group.

How do I know this without the source?  Well, one of our programmers
decided give "adb" and "sdb" a workout, and ... to make a long story
short "found" out what async_main was doing.  Running tests on several
machines proved our theory.

I still don't understand why async_main was programmed this way.  Does 
anyone have a good reason for it trying to change group?  It only stops
the real owner from accessing his/her files when the system gets messed
up or confused.  

--

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Chris McCoy                         : INTERNET:   mccoy@ecn.purdue.edu
Communication Systems Programmer    : UUCP:       ...!ecn-ee!mccoy
Ag. Computer Network, Purdue Univ.  : VOICE:      (317) 494-8339
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=