July 16, 2020 at 12:00 am
Comments posted to this topic are about the item Carefully Giving Normal Users Security Permissions
July 16, 2020 at 4:02 am
This is what I use stored procedures for. The store procedures are each crafted to do one an only one thing, to do it well, and to do it with limits. You don't give the user privs to do what the stored procedure does. You only give they use the privs to execute the stored procedure with parameters. Of course, the parameters are carefully examined. The user can't even see the definition of the stored procedure. I even have stored procedures that necessarily use xp_CmdShell and things like TRUNCATE TABLE... the user is capable of using the stored procedures but cannot use xp_CmdShell nor the TRUNCATE command directly.
The bottom line is that it's almost always not necessary to give users any additional privs other than to execute a given stored procedure.
--Jeff Moden
Change is inevitable... Change for the better is not.
July 20, 2020 at 5:53 pm
Years ago, when I, as well as others, had root password for the various Unix systems in our test lab, one particular employee wanted the password to root so he could do some things. I particularly didn't trust the guy's skills with the Unix commands; heck he could possibly do an "rm -rf /". The su command is in the /bin directory. I added a script called su in /usr/bin that asked for a password and then changed the prompt from a "$" to "#" signifying that the person had superuser privileges. I modified his profile so /usr/bin would be searched before /bin.
He was happy and didn't notice the difference.
Viewing 3 posts - 1 through 2 (of 2 total)
You must be logged in to reply to this topic. Login to reply