[comp.unix.xenix.sco] Problems with guest login script

jtb@abode.UUCP (John P. Gibbons) (10/10/90)

 Hi friends..

      On our system we grant shell (sh) accounts for various people for
use with usenet news and mail etc.. Currently we have no way for any user
to "login new" so to speak. We HAD a guest login script that would ask the
user for various information and then mail root with the information in order
for us to setup a login ID. But we had a lot of problems with it. And now we
can't get it to work at all. 

  What we did was have the guest accounts login shell be the actual script
file instead of rsh or sh (etc) and once the script completed it would log
the user off and we had no security problems. But of course it NEVER worked
correctly. Xenix won't allow the script to send mail, and won't allow the
script to direct to /dev/null which, of course, are both problems.

  If anyone has successfully gotten such a beast to work, I would be VERY
greatful if you could EMAIL me the script (along with any specific info or
instructions for its use).

  If nobody HAS such a script any idea on how to get one to work, (maybe a
small example that actually sends mail to root) would be great too, then I
could write my own.

  btw, to avoid confusion, I want to clarify a few things regarding the
problem. If I am to run the script once logged in using sh then it runs fine,
but will not run if executed as the guest logins shell. Giving the guest
login a shell account and executing the script from the .profile will work,
but once the script is done/aborted they get full sh access. Not good. We
COULD use rsh, but we haven't tried, and more importantly it again would give
more access than we would wish to grant to new users. We just want an online
application so to speak.. 

At any rate, I truely hope someone here can help, please direct replies to
email, and of course as usual if requested I could post a summery of replies.

Take Care,
John P. Gibbons
--
Internet: jtb@abode.wciu.edu
    UUCP: uunet!elroy.Jpl.Nasa.Gov!wciu!abode!jtb
-- 
  //   John P. Gibbons      uucp: ..!uunet!elroy!wciu!abode!jtb
\X/    El Monte, Ca     Internet: jtb@abode.wciu.edu
"From the moment I could talk, I was ordered to listen." -- Cat Stevens

daveh@marob.masa.com (Dave Hammond) (10/13/90)

In article <83@abode.UUCP> jtb@abode.wciu.edu (John P. Gibbons) writes:
> [ about getting the shell to exit after executing stuff in .profile ]
>
>  btw, to avoid confusion, I want to clarify a few things regarding the
>problem. If I am to run the script once logged in using sh then it runs fine,
>but will not run if executed as the guest logins shell. Giving the guest
>login a shell account and executing the script from the .profile will work,
>but once the script is done/aborted they get full sh access. Not good. We
>COULD use rsh, but we haven't tried, and more importantly it again would give
>more access than we would wish to grant to new users. We just want an online
>application so to speak.. 

The shell can be told to exit after executing commands in .profile, in
at least 2 ways:

1. Add `exit' as the last command in .profile:

	# .profile
	new_user.sh
	exit

2. Stick `exec' in front of your new-user script call within .profile:

	# .profile
	exec new_user.sh

In the first case, the shell exits after all commands in .profile are executed.
In the second case, the shell overlays itself with the new user script.

--
Dave Hammond
daveh@marob.masa.com
uunet!masa.com!marob!daveh

hb@vpnet.chi.il.us (hank barta) (10/14/90)

> 2. Stick `exec' in front of your new-user script call within .profile:

> 	# .profile
> 	exec new_user.sh

> In the second case, the shell overlays itself with the new user script.

Just a question about the second case...

Since the script is not directly executable but must be interpreted
by a shell, is there some way the user can get back to the shell itself?


hank

daveh@marob.masa.com (Dave Hammond) (10/14/90)

hb@vpnet.chi.il.us (hank barta) writes:

>> 	# .profile
>> 	exec new_user.sh
>Since the script is not directly executable but must be interpreted
>by a shell, is there some way the user can get back to the shell itself?

No.  The shell does this by doing an exec{l,v} without first forking to
create a new child process.  This overlays the parent process (be it a
shell or any other program) with the new process, rather than creating a
subprocess.

The shell probably invokes another sh and passes it `-c new_user.sh',
although it might avoid the exec{l,v} by special-casing scripts and
internally simulating the above action.

--
Dave Hammond
daveh@marob.masa.com
uunet!masa.com!marob!daveh

shwake@raysnec.UUCP (Ray Shwake) (10/17/90)

>In article <83@abode.UUCP> jtb@abode.wciu.edu (John P. Gibbons) writes:
>> [ about getting the shell to exit after executing stuff in .profile ]

	[ Can't access .edu sites, thus the following posting. ]

Perhaps I'm missing something in John's original inquiry. Why not simply
run a shell script AS the shell, that shell script containing those
assignments and operations that would have gone into the .profile.

For more than a year I've been running a dialup demo for "guest" logins,
the password entry for which reads something like:

	guest:*:204:99:guest login:/usr/demo:/usr/demo/guest.sh

Through proper use of traps, SHELL assignments and other tricks, I've 
kept everyone out of an interactive shell.