Restrict User to a few commands help needed

[sephlaire]

I am running RHEL release 4 (Nahant Update 6).

The situation:

I currently have a fax server that has been encountering issues recently after hours. My boss would like our helpdesk to monitor the status of these modems throughout their shift. This has led to a request for a helpdesk account to be created on our linux box that only has access to a few commands.


Is there a way to limit the new user to only have access to the following commands?

cd
less
cat

Additionally I would like to create a script for them to run that would chmod our modems when necessary since their permissions reset after a power cycle. BUT not give them access to the chmod command, just chmod through that script for those specific devices. (I know this might be more difficult if not impossible but I'm not 100% sure which is why I am asking)

If anything I'm asking is either not possible or not practical please let me know a possible solution for my problem.

[Irithori]

There are two issues
1) the permissions after reboot
2) helpdesk being able to monitor modems

for 1)
This is a setup issue.
Maybe this helps
redhat.com | Red Hat Magazine - Configuring Devices with udev

And if all else fails, place the chmods in /etc/rc.local

for 2)
I would suggest *not* to use login shells.

Not exactly sure *how* you monitor your modems.
But maybe a custom plugin to a monitoring solution of your choice (munin, xymon, nagios, etc)
or a cronjob, that executes a script to produce files every X minutes will do.
These files could then be exposed via apache/http.

This way, the risk is reduced to a minimum.
ReadOnly access via browser (potentially password protected) is way more secure than trying to lock up a shell access.

[sephlaire]

Our modems are monitors by issueing the command:

cat server_info

server_info is a file within a directory. The problem is that I cannot make any 'major' changes to this server which include installing any application including apache/http services. This is mainly due to the fact that this fax server is running a piece of healthcare software that is part of a much larger suite. Although we own the physical equipment, our support contract will not let us make changes to running applications without approval which will not happen anytime soon.

I do however really like your idea so tell me if you think this would work...

Create a cron job (or script) that would copy the 'server_info' file and FTP the file to our in-house RHEL web-server every 5 minutes(or other desired time). Since I have full authority over the web-server I could then make it available through a web interface easily.

[Irithori]

Well, this idea is more like a ducttape approach than a real monitor
These provide you with history and nice rrd graphs for various metrics:
Munin :: ping.uio.no :: tetra.ping.uio.no

But if you want to keep it simple:
- It doesnt matter how you copy that server_info file over to your webserver.
Whatever is simplest for you: ftp, scp, rsync, etc
- I would at least add a timestamp into that (text) file, so that one can see if the data is up2date or not.

[sephlaire]

Thank you for your help.
This 'monitor' is more of a feel safe short-term(6-8 months) fix for management and our helpdesk. In the longterm we are purchasing a new server with built-in modems since our current set-up is a nightmare that I inherited when I took my position. We have multiple fax modems sending simultaneously but these are attached to a USB hub and that hub is connected to the server over one USB port. The software sending faxes doesn't work well with this setup according to our vendor.

I should be able to get this ducttape monitor up and running tomorrow so thank you again for your input.

[Irithori]

Additionally you could implement alerting. Ducttape style

It depends a bit on that server_info.
Either diff it against a "known good" server_info_template
or
grep it for ERROR (or similar)

Either way:
If server_info indicates a problem, send a mail to your helpdesk mailaddress.

[sephlaire]

I like that idea a bit better. Instead of shipping the contents of 'server_info' to another server, I can try making a script for cron to run that could automate the process.

For example: awk for error, if specific error exists execute know fix... if fix does not resolve the issue notify (via email) helpdesk or myself.