My employers would like me to selectively run one of several different (already-existing) Korn Shell menu-driven scripts out of the user's .profile file, depending on some yet-to-be-specified user critieria.
I've never done this kind of thing, but I have the existing scripts (among other things) to look at.
One of the classic concerns when writing such a login menu is the user's ability or inability to break out of it. I'd read that this is where the shell "trap" command is used to trap signals that would normally break out of the script. But the existing scripts don't do that. Instead I see lines like:
stty susp <undef>
stty quit <undef>
and so forth. This undefines the key sequences for interrupt, suspend, etc.
It seems to me that maybe this is a better approach than the 'trap' command, because it does not disrupt the default (and presumably better-thought-out) handling of signals caused by things other than the user pressing keys.
Does anyone have any experiences/opinions about this? Which is the better approach?
Also, what are the advantages/disadvantages/dangers of actually replacing the user's login shell in the password file with the menu script?
Finally, is there any such thing as a generalized (and presumably compiled) menu shell that takes text files of choices and actions as inputs? I could not find any such thing in via Google.
you can compile a shell script using the shc tool, you have to compile the tool on your machine. Francisco Rosales, home page
DO NOT make the users shell the shell script
One of the best approaches is to chroot the user. Create a chroot jail. The only downside is that you have to have copies of ALL the shells, commands the shell scripts call, and any special application code etc., - inside the jail. One copy for everybody is fine. Even if the use gets "out" of the menu somehow, he/she cannot do much.
This gives an overview and some howto. If you want to try it there are dozens of tutorials on the net. google for 'chroot howto'
another choice is to use a restricted shell - usually /bin/rsh as the login shell, check your documentation.
Run the menu under that shell. Again it may or may not be a choice, but check it out anyway.
On purpose, I kinda ignored the signal trapping. When you set things up well to start with, signal trapping is a lesser concern.
In addition to disabling certain keys with "stty" one basic precaution is to "exec" the menu script as the last line of the user's login profile thus reducing the chance of being dropped to a shell prompt.
I'd consider trap safer because it can eat a SIGINT from any source -- kill and the like -- not just those that come from the keyboard. Besides, who's to say you don't want the program to do something on ctrl-c?
The main advantage of changing their login shell to your script is that, if they manage to kill it somehow, all they accomplish is logging themselves out. There's no interactive shell behind your application to "break out" into. Disadvantage is that it can be harder to arrange. Some systems need you to add your application to /etc/shells before they'll let people use it as their 'shell'.
I'm sure there's general-purpose menu systems. Of course, just because something's compiled doesn't mean it doesn't have holes -- it just makes it harder to know whether it has holes...
I thought about chroot, I may try that. As they so often are, the requirements for this task are very nebulous, but I get a sense that part of what I am doing is protecting DBA's from each other, so moving them all into the same chroot'ed envionment may not be a good idea.
The environment is AIX, and I understand that AIX has something alot like Solaris Zones, called logical partions or LPARs. Maybe I should look at that, if they are like Zones then I can give everybody read-only access to one set of executables w/o using any more storage.
I too am interested in specifically why replacing the user's login shell is a bad idea, beyond the obvious objections like I could write a crappy script, etc.