mccoy@ea.ecn.purdue.edu (Chris A McCoy) (03/29/90)
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.
The conditions are as follows:
1) Whenever he tries to edit his modem profile using either
the UA invocation or the corresponding shell invocation.
2) When he calls a remote system using the OBM, after the
Phone Manager calls async_main.
Both instances occur when starting /usr/bin/async_main as any standard
user from any terminal, including the console; however, if the user is
"root" no failure occurs.
I've checked the permissions on "async_main" and and his modem profiles
and all are consistent with working systems. I can't find any other
files that async_main seems to be accessing when editting a modem
profile.
Has anyone experienced this problem and found a solution?
Does anyone have the source code for ATE and can track down why
this problem occurs?
This problem has stumped three systems programmers, and we're about to
pull out all of our hair.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Chris McCoy : INTERNET: mccoy@ecn.purdue.edu
Communication Systems Programmer : UUCP: ...!ecn-ee!mccoy
Ag. Computer Network, Purdue Univ. : VOICE: (317) 494-8339
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=mccoy@ea.ecn.purdue.edu (Chris A McCoy) (03/30/90)
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 =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=