Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations SkipVought on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

restrict access to performance tools

Status
Not open for further replies.

ciman

Technical User
Feb 17, 2007
14
0
0
DE
Hi,
we encounter problems because many users open tools to analyse performance during times of high system loads and setting lower ulimits is not an option.

Changing the file permissions on tools like topas does not really help because they could be copied and started locally.
My idea is to restrict access to the data source for certain user groups. Did anyone experience similar problems?

Thank you in advance!
ciman

 
You can always use restricted shell (tsh) to prevent users from having more power than they should!

But for your case, how about moving the topas and the other performance tools from the bin directory and put them in another directory that is only accessible by root (and other powerful users)? You can include this directory in your PATH!

Never tried that option so it worth testing before doing it!

Regards,
Khalid
 
Thank you for your response Khalid.
I've also thought about putting tools like topas in a directory not accessable to normal users or changing the file permissions. But this does not really help because the users can easily copy the needed files from another system.

What I'm looking for is a way to prohibit tools like topas or vmstat from accessing system performance data.

Regards,
ciman
 
Why don't you try sudo? As far as i remember sudo let normal users access files that are only accessible by root (for example or other power users)! The same thing can be applied to prevent users from running topas or other performance tools!

Regards,
Khalid
 
To back up Khalid's suggestion
[ol]
[li]chmod 700 topas[/li]
[li]mkgroup topasusr[/li]
[li]add privileged users to topasusr[/li]
[li]in sudoers add the line %topasusr myhost=/usr/bin/topas[/li]
[/ol]
I'm doing the sudo syntax from memory so I may have got it wrong.

On the internet no one knows you're a dog

Columb Healy
 
Further to my previous post I've checked out my sudoers file and the relevant entris look like
Code:
Cmnd_Alias MON_TOOLS = /usr/bin/topas, \
                       /usr/bin/nmon, \
                       /usr/sbin/sar

oracle myhost = MON_TOOLS
%livesup myhost = MON_TOOLS
This allows the user oracle and any users in the group 'livesup' (Live Support) to run topas, nmon or sar as root using sudo.

On the internet no one knows you're a dog

Columb Healy
 
How do you prevent, like ciman already said, that the users just copy the binary from another box locally to their home?

ciman wrote:
But this does not really help because the users can easily copy the needed files from another system.

laters
zaxxon
 
Ok, yet another way of doing it (just trying to think out of the box) is to set a company IT policy of preventing the use of such tools! and then keeps monitoring those tools (through a crontab job for example that notes down the users running the performance tools at that time and then you can take that list to send warning to those users to stop playing around).

I'm sure this will be difficult at first (if you don't have a strong management to back you up) but after some time you will sure get rid of such annoying problems.

Regards,
Khalid
 
i think if you go down the route of blocking users from accessing the performance data itself you need to either remove libperfstat(not good) or start restricting perms on the libraries topas uses... this wouldn't be a good tactic either because:

a) not sure if changing perms on libperfstat will have any other undesirable effects.. you'd need to test this out... maybe use genld to see what else is actively accessing it

b) you're changes get undone with every patch update of the libs in question.

c) i'm just generally of the opinion this is a drastic measure.

I agree that the best approach is to set a policy which prohibits this kind of stuff and get management approval to enforce it.

if management doesn't want to enforce it then let management worry about poor performance.
 
Rename or remove topas binary, and use nmon instead. :)

yes, i know they are now the same, but im assuming your not at AIX 6.1 TL2 or 5.3 TL9 yet. :0)
 
Thank you for your suggestions and comments.
There is probably no easy way to solve the problem.

Scanning process tables is also nearly impossible because locally started software can carry any name and locally compiled software usually varies in size.

The only hint I can get is which shared libs are being used.

Ciman
 
Try (Not tested)

Move topas to topas.root and chmod 700, Create a new file topas containing:-

Code:
/bin/topas "$@"
case $(whoami) in         # Check effective user ID name
root)    topas.root
*)       echo "Sorry this command can only be run by root"
         ;;
esac



Mike

"Whenever I dwell for any length of time on my own shortcomings, they gradually begin to seem mild, harmless, rather engaging little things, not at all like the staring defects in other people's characters."
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top