hi
Aix role system is really not very good.So if you want to allow that user to run
savevg,sysback or mksysb you have to make this user "root equivalent".
For security reasons you may consider to setup restricted shell for the user or
allow him to execute only specific commands.
Sudo (superuser do) allows a system administrator to give certain users (or groups of users) the ability to run some (or all) commands as root or another user while logging the commands and arguments.
I dont know if you're still having problems. But, the only way to give a non-admin user root access, is to make the USER ID number of the user, identical to roots. You can't do this via - smit user, the only way, is to edit /etc/passwd. To stop the user from accesing the command line, change his .profile, so he logs into smit backup, and set a trap in his .profile, which will prevent him from breaking out to the unix shell.
That is highly NON-recommended. This is based on security issues. Like I had mentioned before.... the utility "sudo" will do exactly what you need to do to accomplish this by giving the user the ability to run, for example, ONLY the backup utilitie(s) you want and that's it. If sudo is used as it is designed to, you will not have any security issues to deal with as with giving another USER the root ID 0!
hi
chuck is absolutly right.
i am practising same thing on my site.
i hav given some users the specific rights thro. sudo.
its very simple and easy to configure. u wont hav any security issues. dont change the users id to 0 this will give him all rights as root.
bye
nan aix sys admin
***************
u can reach me at
nandkumarg@visto.com
There would only be a security issue, if the user was given access to the command line, not if, for example you had a backup user id, which logged U straight into smit, or a backup shell script.
I beg to differ. There could be a big issue if before the execution of the backup shell script, the user were to 'break' out of the script and get to command line.... or during the script, if you didn't have ALL escape sequences trapped, a user could break out of the script and get to a command line.... as root. BIG security issue.
If it were smit(ty) they were going into.... remember.... you would have them in smi(ty) as root.... VERY bad becuase you can do almost everything from smit(ty) as you can from command line.
Although I agree, that if the user was allowed into smit, they could potentially do anything, if they were logged in as root. However, if you were going to login as a backup user, which had root privileges, but the user was logged into a backup menu, and smit wasn't used for the backup, you could trap escape seq 2
trap ""2, and there is no way of breaking out to the command line.
There IS a way to break out of it! I have done it!
All that the .profile is a "login script" to execute commands in cronological order, one command at a time. As soon as you login, you CAN (It has been done successfully) break out of the script at a point BEFORE the execution of the "execution of the menu script". When that is done.... you will be at a command line.... as ROOT!! Also, if the "menu script" is called WITHOUT exec command in the .profile, and depending on what options you have in the "menu script" to supposedly "logout" of the menu script when you are done.... could end you back at a prompt.... as ROOT!
Can't you prevent the user from breaking out by catching the INT and HUP signals in the .profile? Mike
michael.j.lacey@ntlworld.com
Email welcome if you're in a hurry or something -- but post in tek-tips as well please, and I will post my reply here as well.
You can catch the INT and HUP signals in the .profile... but it depends on where in the .profile you are catching (trapping) them at. If done right... you can still break out the the .profile execution BEFORE the INT and HUP signals are set to be trapped. Remember though that this is an extreme, and most "users" don't know about this... but there are those that do... and would YOU leave them the chance to gain unauthorized access?
Quite right Chuck, no sense leaving the script wide open, I trap them on the first and second lines. Mike
michael.j.lacey@ntlworld.com
Email welcome if you're in a hurry or something -- but post in tek-tips as well please, and I will post my reply here as well.
This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
By continuing to use this site, you are consenting to our use of cookies.