As always, lots of great responses.
MY QUESTION:
I was just told that many Sun workstations need to be moved tonight. I do
not want to have to stick around just to shut them down, but I don't want to
give out the root password (NIS+) either.
I was thinking about creating a user called shut who is a member of a group
called shut. Then write a shell script that calls init 5. Make that script
suid root and executable by the group shut.
Then have the users log in as shut. Shut's .profile could call the script
above that shuts down the system.
1) Will that work?
2) For the long term this is bad because anyone could rlogin to any
workstation and shut it down! That's bad. How can I give users the ability
to shut down or reboot their own workstation (i.e. only on console)?
SUGGESTED SOLUTIONS:
1) Use the power key to suspend the system. I had considered this but have
not been able to get it to work on any systems. Some could not stop a driver
and went back to the CDE desktop. Might have been due to the SunPCi cards,
though not all had a problem. Others seemed to suspend fine, but would not
start up again and had to do a full reboot.
2) Create another user besides root with user ID 0. I did use this
technique, with a .profile that checked if the user was on /dev/console and
then ran shutdown. This forced them to do a Command Line Login so they were
on console. Without the /dev/console check, I tried to use it with a regular
CDE login, but CDE would never load--I guess the shutdown started before CDE
was up and it hung dtsession.
The problem here is that there were recently messages on this list saying
that having more than one ID 0 user can be a problem. It is pretty strange,
the new user can't edit any files--only the real root can. It makes me
nervous so I'm going to delete that user.
3) My original idea, an suid script executable by a group that has only one
member, the userID I want to be able to do a shutdown. Alas, I absolutely
cannot get the suid script to work. I get:
/dev/fd/3: Only root can run /dev/fd/3
(SunSolve says it is normal for an suid script to not report its name, only
its file descriptor for security reasons.) It still seems to be running as
the user, not root. I can get an executable to run suid, e.g. snoop.
Permissions are the same on both: -r-sr-x--- 1 root shut
Apparently my lack of SA experience is showing, though a couple of people
said suid shell scripts never work.
Many are very uncomfortable with suid scripts. I can understand this.
4) cron job. Perfectly acceptable solution in some cases but doesn't really
work for me. I was not sure if this move would actually take place or which
systems it would be. Many users run extended simulations, so they'd
appreciate their systems staying up as long as possible.
5) Stop-A. sync: seems barbaric :-) For performance reasons, home
directories are local so data corruption was more likely than if they were
NFS mounted homes.
6) Modify /etc/dt/config/Xstartup to check for a particular userID and run
shutdown if there's a match. That's interesting. I did not get chance to try
that one. Maybe I should!
7) sudo: This application looks like a long term solution. It allows me to
set up a list of commands and users who are allowed to execute them. I liked
some of the above solutions better because it forced the user to log out,
making sure that all his apps were closed nicely before a shutdown. Seems
like an accident waiting to happen if they can just type shutdown and lose
all their work.
Well, that's the summary. I got by that night with a second user with ID 0.
I tried making that user's shell a script, even added the path to the script
to the /etc/shells, but that didn't work. Had to use .profile. So I'm still
weighing the options, but I appreciate receiving so many!
Thanks to everyone.
-Tom Stanley
S
U BEFORE POSTING please READ the FAQ located at
N ftp://ftp.cs.toronto.edu/pub/jdd/sun-managers/faq
. and the list POLICY statement located at
M ftp://ftp.cs.toronto.edu/pub/jdd/sun-managers/policy
A To submit questions/summaries to this list send your email message to:
N sun-managers@sunmanagers.ececs.uc.edu
A To unsubscribe from this list please send an email message to:
G majordomo@sunmanagers.ececs.uc.edu
E and in the BODY type:
R unsubscribe sun-managers
S Or
. unsubscribe sun-managers original@subscription.address
L To view an archive of this list please visit:
I http://www.latech.edu/sunman.html
S
T
This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:14:21 CDT