why can only root can run make_recovery?

[Tom Gore]

Why is root the only signon that can run make_recovery?

What would I need to do to allow another signon (our operators) to run make_recvoery? I want them to be able to use their individual sign ons to run make_recovery, but not be "all powerful" like root.

Thanks

[Mark Grant]

I imagine that it'd partly becuase you need read access to all files in order to back them up. You don't want to give users read access to all your configuration.

[Pete Randall]

Tom,

Why? It's part of an administrator's job to make sure the system is adequately protected from catastrophic failure. There may also be some security issues.

In order to delegate this task, look into "sudo":

http://hpux.cs.utah.edu/hppd/hpux/Sysadmin/sudo-1.6.7p5/

Sudo can be set up to allow non-root users access to various commands just like they were actually logged in as root.


Pete

[A. Clay Stephenson · Accepted solution]

Consider this: Unless a super-user runs make_recovery how could you be assured that all files would be accessible? You could use sudo to give this capability to your operators.

[Patrick Wallek]

The make_recovery and make_tape_recovery processes MUST be able to read all files in VG00 and must be able to execute certain OS commands and utilities. root is the only id with this access.

You could install something like sudo, which would allows users to run commands as root without knowing the root password. You could then write a script that would run your make_recovery (you really should be using make_tape_recovery) and then set sudo up to allow your operators to run this command via sudo as root, but they still don't know the root passwd


Sudo can be obtained from:

HP Porting Centre
http://hpux.connect.org.uk/hppd/hpux/Sysadmin/sudo-1.6.7p5/

or

The actual home of sudo:
http://www.courtesan.com/sudo/

[Steven E. Protter]

Only root has the access needed to do a make_recovry backup.

make_recovery is obsolete you should be using make_tape_recovery

I have that job run out of root cron. Operations just puts the tapes in before 2 p.m. on Friday.

I am attaching a good script.

SEP

[Tom Gore]

Thanks to all. I was not aware of sudo. I will look into that and see if this is something that can loaded on the system (have to get the proper authorization, etc from the managers). In the meantime, I may try the cron solution.

One question to Steven-how do you handle the holidays when nobody is there to load the tape?

[Tom Gore]

Steven-I just thought of another issue. Every once in a while our ignite backup goes to more than one tape. If the job is in cron what notification is there that another tape needs to be loaded? Rignt now, since it is being run "interactive" the operator is presented with a message to load another tape. Also, if it runs on a day when there is no operator present (holidays), what will happen?

Thanks

[Patrick Wallek]

With regard to holidays, you could set up a file with your company holidays in it and modify your script so that it does something like:

if [ not a holiday ]
then
run make_tape_recovery
else
don't run it
fi

A. Clay Stephensons caljd.sh or caljd.pl script could help you with this. Try searching the forums on "caljd holiday" and see what turns up.

With regard to the multiple tape issue -- if you are running make_tape_recovery from cron, there is *NO* notification about it needing a second tape, the job will fail! Since cron is non-interactive there is no terminal for make_tape_recovery to send a prompt to and it will, I believe, record such an error in its log.

Sudo is probably your best bet.

Another thought I just had though is you could try writing a script that will run the make_tape_recovery command and then make that script executable and a set-uid script, change the owner to root, the group to something that only your operators have, and then let them run it from there. That *SHOULD* work, but I am not certain.

[Tom Gore]

Patrick-thanks for your input. I went looking for setuid. All I found was the man page. Where can I get setuid?

[Mark Grant]

Pete,

I didn't think setuid scripts were possible these days.

Tom,

SETUID is how sudo works. It is an OS feature that allows you to run a program with the same right as the owner of the program. So, if you have a file owned by root that is SETUID and a normal user runs it, it will run with root authority.

I don't believe you can have SETUID scripts anymore so normally you would need a "C" wrapper to start the shell script and SETUID that instead (this is pretty much what sudo is). You make something SETUID by "chown" to the user you want it to run as and then something like "chmod 6755" the file.

[Pete Randall]

Huh????? I never mentioned anything about setuid. Maybe you meant Patrick????


Pete

[Mark Grant]

Sorry Pete!!

Maybe you were going to mention SETUID and I just sort of telepathically picked it up. Is that possible at all?

[Pete Randall]

Mark,

No problem, however, I wasn't even thinking setuid so any prognotication on your part was really "far-seeing".

;^)


Pete

P.S. No points, please.

[Patrick Wallek]

Sure, you can absolutely still have SETUID scripts. Now you can disable setuid on a filesystem when it is mounted with the mount option 'nosuid'. The default if nothing is specified is to allow suid.

Anyway, I just did a test with the print_manifest command. I tried running as a regulard user and got the message that I must be root. No big surprise there.

So I created a short script:

#!/usr/bin/sh
/opt/ignite/bin/print_manifest > /tmp/manifest

The script was called printm and I put it in /opt/ignite. I then did a 'chmod 4555 printm' to make it executable and set the setuid bit. I made sure the owner of the script was root.

I then logged back in as a regular user and ran /opt/ignite/printm. It worked like a champ and created the /tmp/manifest file with the print_manifest output.

So you could do the same basic thing with a script to run your make_tape_recovery. Maybe something like:

# vi /opt/ignite/run_ignite

#!/usr/bin/sh
/opt/ignite/bin/make_tape_recovery -a /dev/rmt/?mn -m tar -I -v -x inc_entire=vg00

Then do:

# chown root:sys /opt/ignite/run_ignite
# chmod 4555 /opt/ignite/run_ignite

Now when your operators log in with their id they just do:

$ /opt/ignite/run_ignite

And the make_tape_recovery process should start. The output will go to the screen and this way they should be prompted if a 2nd tape is required.

Good luck.

[Tom Gore]

Thanks for clearing things up for me Patrick. I will do a little "playing" with your suggestion. This may be the better way to go for now. I don't have to download any additional "routines" (sudo). I can use what is already there.

[Tom Gore]

Patrick,

It looks like I will have to load sudo. My testing did not work out so well. Although I can run "run_ignite" as a user, that user does not have authority to some of the filesystems. The ignite cancels due to file permission errors.

[Patrick Wallek]

Tom,

I just tried a setuid script on a test box as well and I could not get it to work. I had not tried it before, it was just a shot in the dark to try to save you from having to install something else.

I think sudo will be the way to go tough. That will also enable you to delegate future taks to your operators as well without worrying about giving them the root password.