From Eric Freden on Fri, 04 Dec 1998
Here is a legitimate use for remote login as root:
My kid plays some svga game on my console and locks the keyboard (for instance). I want to telnet in and /sbin/shutdown -r now
Actually you can often recover from this without a shutdown. But its a trick. Eventually we might have something like KGI/GGI to provide more robust SVGAlib support.
(The trick is to start X from your telnet/terminal session. This usually does a complete video system reset as a side effect. WARNING!: This might hang the system --- so close any running text mode apps, save any accessible documents and issue a few calls to 'sync' before trying it).
For RedHat 5.0 (and all other RedHat versions I've used) only root can do this. Changing to su and executing shutdown won't reboot! Perhaps you could find a workaraound for this scenario?
If that's your experience then something is wrong with your 'su' command!
Did you issue 'su -' (the dash is pretty important --- as it forces the 'su' command to run your .login/.profile scripts and initialize root environment (and shell variables, etc).
Another approach is to tweak the permissions on 'shutdown' Here's the recommended method:
Create a group such as "shutdown" or use the "wheel" group.
Add your regular user account (and mom's?) to that group.
Issue a command like:
chown root.$GROUP $(which shutdown)
... to set the file group association appropriately. You could also use 'chown' then 'chgrp' seperately, of course.
Make it SUID with a command like:
chgrp 4550 $(which shutdown)
N.B. I set the execute bit for owner and group but not for "other/world"
This allows people in the associated group to issue the 'shutdown' command. That command will run with root' privileges. The 0 permissions for "other" prevent "others" from executing this command at all. (Other users have no valid reason to issue a shutdown command).
Setting binaries to be SUID always has implications for system security. However, it is one of the primary forms of authority delegation available in Unix/Linux.
In this case we minimize the risk by limiting the number of accounts that can access the command.
This technique is generally useful and should be considered for all Unix/Linux SUID commands.