Carefully Giving Normal Users Security Permissions

  • 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

    RBAR is pronounced "ree-bar" and is a "Modenism" for Row-By-Agonizing-Row.
    First step towards the paradigm shift of writing Set Based code:
    ________Stop thinking about what you want to do to a ROW... think, instead, of what you want to do to a COLUMN.
    "Change is inevitable... change for the better is not".

    Helpful Links:
    How to post code problems
    How to Post Performance Problems
    Create a Tally Function (fnTally)
    Intro to Tally Tables and Functions

  • 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