Some shops use a unix tool called "sudo" as alternative.
----- Original Message ----- From: "Thomas Denier" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Friday, February 08, 2002 1:20 PM Subject: Re: root required to kill TSM daemons? > > We just converted to TSM 4.2.1.9 from NetBackup. We are finding that our > > group needs to be able to stop the TSM daemons and start the start up > > script, instead of always having the system admin. do this. Right now I am > > told that there is no work around for root privileges being needed to kill > > the TSM daemons. I'm wondering how other shops get around this problem? When > > our TSM server crashes, all of the clients that are getting backed up are > > getting hung schedulers and need to be bounced to resume working. The fact > > that root privileges are needed to bounce the daemons is adding on days to > > our resolution, since we have to open a problem ticket with the system > > admin. group and wait for them to bounce the daemons. We have ids on most of > > the unix servers and could do it, if the permissions allowed. > > > > Any ideas?? Do any of you have a work around for this problem? Tivoli had me > > open an enhancement request. > > I either have root access or can get reasonably quick responses from > administrators on all of my site's TSM client system. If I were in your > position I would have the administrators install a perl or shell script > that would kill any running 'dsmc sched' process and start a new one. > > The administrators would have to do one of two things with the script: > > 1.Make the script root owned, executable by your ID, and SUID. > > 2.Write a small (six lines or less, depending on one's white space > conventions) C program that uses the 'execv' function to run the script, > compile the program, and make the object code root owned, executable by > your ID, and SUID. > > The SUID attribute causes an executable file to run with the authority of > its owner rather than the authority of the person invoking the program. > Many UNIX implementations still have an ancient bug that makes a script > with the SUID attribute a serious security exposure. If your client systems > have this bug you will need the second approach despite its additional > complexity.