I have a Debian 5.0 server that my company uses for deployment testing. This server needs to be accessed by NOC people that have no NIX knowledge whatsoever.
I am creating a bash script for a menu-based command interface for the commands they need to run on their testing routines, but I wanted to know how can I force a user, upon login, to access this script (when he logins, this script is run) and nothing else (when he is finished, i.e., choose "X" for exit), the system log out the user.
You can create a log in hook, that when that specific user logs in, say via ssh a script runs. Then you can post an interactive script that runs with that log in hook...
example:
#!/bin/bash
selection=
until [ "$selection" = "0" ]; do
echo ""
echo "Select an option please"
echo "1 - Do something"
echo "2 - Display something"
echo "3 - third option"
echo "4 - Print something"
echo "5 - List some stuff"
echo "6 - Display system information"
echo "0 - exit and log out"
echo " "
echo -n "Enter selection: "
read selection
echo ""
case $selection in
1) some command ;;
2) some command ;;
3) some command ;;
4) some command ;;
5) some command ;;
6) some command ;;
0) exit and log out ;;
*) echo "Please select a valid option"
done
That is just a quick and dirty example, and you would of course have to input the text and the related commands. I have used a similar script in the past to automate imaging PCs with Zen imaging from Novell. You can probably have init.d run this but I am a bit rusty on that.
Yep, I mean, I have my script done on bash for the commands, but what I need help is how I hook it to the user login, and make sure that when the script exits, the user gets logged out...
All of my *nix work in the past 5 years has been on the Apple platform so I am really loving launchd for this exact sort of thing, however, /etc/init.d should be able to do lots of similar things. So you would want to put your script in /etc/init.d/myscript but I am not quite sure how to make it user specific. In debain do they have any init.d run level stuff in a user's home folder?
The only other thing I can think of, is edit that user's bash profile (.profile, .bashrc, or whatever it is in Debian) to execute that script as part of the bash start up (or whatever shell you are using) that way when they ssh into the server it will auto execute at their user level.
Depending on the system you may also need to add it to /etc/shells in order to allow it. But otherwise, this should work well for most UNIX systems -- the original script gets run directly, with no intermediate commands the user can interrupt, redirect, fold, spindle, or mutilate.
Note that it becomes your script's responsibility to set up its environment properly since there's no longer a login shell to do that for it -- it is the login shell
For further restriction yet your script could use a feature-restricted shell like /bin/rbash, which greatly reduces the shenanigans possible even if the user somehow manages to inject arbitrary input into your script. Or just make the user's login /bin/rbash and call your script from their bashrc files.
Okay, I'll try some of this tomorrow but it sounds like what I am looking for. I have already on my script the exit commands to logout, but should the user break the script I still want him to be logged out or to return to the script, meaning I do not want him getting to the shell prompt by no means.
If you set your script as their login shell, there's no time during which they can hit ctrl-c and crash the program down to a prompt since it was never run from a prompt in the first place. All they'd do is log themselves out. To get access to arbitrary commands they must run a new shell instance, exploit weaknesses in your input programming, modify your script, or modify their RC files.
If you're worried about security then you'll need to be careful about what commands you use in your menu option.
If you're doing commands like:
echo "2 - Display something"
...
echo "5 - List some stuff"
echo "6 - Display system information"
You may be thinking to pipe multi-page output to less or more so the user can page through it.
A place I once worked had menu scripts that ran as root and paged files with less, which I found rather convenient when I needed a root shell on that box in an emergency... all I needed to do was go into the menu and choose the file viewer and type !<Enter> and I had a root shell!
If you read the less man page you will find:
When the environment variable LESSSECURE is set to 1, less runs in a "secure" mode. This means these features are disabled:
! the shell command
| the pipe command
:e the examine command.
v the editing command
s -o log files
-k use of lesskey files
-t use of tags files
metacharacters in filenames, such as *
filename completion (TAB, ^L)
That'll be something you'll want to export as a variable in the top of your script if you're going to use less.
When you try to lock something down your own way, using tools that weren't designed specifically for embedding in secure menus, you need to be smart enough to be able to second-guess everyone who will get access to the system, and shut off any loop-holes they could abuse before they find them.
