Author: way0utwest

  • Back

    It’s amazing to think I’ve been gone 10 days, out of the country. SQL Bits was amazing, and still is the best SQL Server conference in the world I’ve seen. I haven’t been to them all, but this is the best of those I go to.

    Ireland was fantastic, and a very warm welcome for a day of training and then a talk at the Dublin SQL Server User Group. Some really interesting questions for me to blog about and answer in the next few weeks.

    Photo Mar 05, 10 40 37 AM

    I saw some neat SQL Server tips, tricks, ideas, and inspirations, which is always a good thing as it motivates me to do more and learn more as my career progresses.

    And I got a new shirt:

    Photo Mar 05, 4 15 07 AM

    An amazing gift from the crew at SQL Bits. My own speaker shirt. I was quite touched and I really appreciate the effort they went to. I know what I’ll be wearing next year.

    Photo Mar 10, 1 52 58 AM

    A few people were jealous, since the "regular" speaker shirts were blue polos. I guess I stand out a bit from them. The Friday night party was fun, with the Captain making an appearance.

    Photo Mar 06, 2 43 03 PM

    All in all a great trip.

    Now back to work.

  • Allowing a User to Create Objects in a Schema

    I was testing something the other day and realized this was a security area I didn’t completely understand. I decided to write a few posts to help me understand the issues.

    I want to give a developer rights to create objects in a schema. In this case, I’ll stick with procedures, but the same thing would apply for tables, views, etc. How do I do this, allow someone to create objects in their schema?

    Let’s create a login and user:

    CREATE LOGIN steve WITH PASSWORD = ‘AR3allyStr0ng!P@**Wo9d’;
    GO
    USE Sandbox
    GO
    CREATE USER Steve FOR LOGIN Steve
    GO

    Now I have a user, and want them to be able to create this:

    SETUSER ‘Steve’;

    CREATE PROCEDURE Steve.MyProc
    AS
        SELECT
                1;
    RETURN

    If the user does this, they get:

    Msg 262, Level 14, State 18, Procedure MyProc, Line 3
    CREATE PROCEDURE permission denied in database ‘sandbox’.

    That’s no good.

    We can see from the error that we don’t have writes to create procedures. Let’s fix that. First, we change our context and then we grant permissions.

    SETUSER
    GO

    GRANT CREATE PROCEDURE TO Steve;

    GO

    With this done, let’s now try creating the procedure again with the SETUSER statement and the CREATE PROC statement. We then get:

    Msg 2760, Level 16, State 1, Procedure MyProc, Line 5
    The specified schema name "Steve" either does not exist or you do not have permission to use it.

    This didn’t used to be the case in SQL 2000, where schemas didn’t exist. Now we don’t have any implicit schema for our user. Let’s see if we can make anything.

    CREATE PROCEDURE MyProc
    AS
    SELECT 1;
    RETURN
    GO

    Returns this:

    Msg 2760, Level 16, State 1, Procedure MyProc, Line 11
    The specified schema name "dbo" either does not exist or you do not have permission to use it.

    At this point Steve doesn’t have permissions to any schema. Let’s start by adding a new schema.

    CREATE SCHEMA Steve
    GO

    Once this is done, can I now create a procedure?

    SETUSER ‘Steve’;

    CREATE PROCEDURE Steve.MyProc
    AS
        SELECT
                1;
    RETURN

    I get this:

    Msg 2760, Level 16, State 1, Procedure MyProc, Line 5
    The specified schema name "Steve" either does not exist or you do not have permission to use it.

    The same error as before. This makes perfect sense because although the schema exists, I don’t have permissions to use it.

    That’s the default in SQL Server. You don’t get any permissions by default. You need to explicitly set them.

    In this case, I want Steve to have control of the schema [Steve], so I really want the user, Steve, to own it. How do I do this?

    The key is that I want to use the Authorization clause with CREATE SCHEMA. I can’t use this with ALTER SCHEMA, only with CREATE SCHEMA.. so I need to do this:

    SETUSER
    GO
    DROP SCHEMA Steve;
    GO
    CREATE SCHEMA Steve AUTHORIZATION Steve;
    GO

    Once this is done, I can now let my user create procedures.

    SETUSER ‘Steve’
    GO
    CREATE PROCEDURE Steve.MyProc
    AS
    SELECT 1;
    RETURN
    GO

    This works, and my developer can work in their own schema. Of course I need to ensure the developer has access to other objects, hopefully using a role of some sort that I’ve created for my application users.

     

    SELECT SUSER_NAME();

    DROP SCHEMA Bob
    DROP SCHEMA steve

    REVOKE CREATE SCHEMA FROM Steve

    CREATE SCHEMA Steve AUTHORIZATION Steve

    ALTER SCHEMA Steve AUTHORIZATION Steve

    SETUSER ‘Steve’;
    SELECT SUSER_NAME();

    CREATE PROCEDURE Steve.MyProc
    AS
        SELECT
                1;
    RETURN

    CREATE PROCEDURE MyProc2
    AS
        SELECT
                1;
    RETURN

    SETUSER;
    SELECT SUSER_NAME();

    GRANT CREATE PROCEDURE TO Steve

    SETUSER
    DROP PROC steve.MyProc;
    DROP PROC steve.MyProc2;
    DROP SCHEMA Steve;

  • Altering a Column with NOT NULL

    A short piece, as I ran into the need recently to alter a column to NOT NULL status. I’ve rarely done this in the past, usually specifying NOT NULL when I create the table. Often in future changes, I’ve been wary of not allowing NULLs since I’ll always find an application, or worse, a business situation where there is no good value available. However that’s a separate discussion.

    Altering the Column

    Let’s say I have a column that is specified as NULL in a table, and I want to change that. I initially tried this:

    ALTER TABLE Tags ALTER COLUMN Status NOT NULL;

    However, I got a syntax error. For the life of me, I couldn’t understand why, so I looked up the syntax. If you look at the ALTER TABLE syntax, it shows that the ALTER COLUMN item needs the type included. While I am not changing the data type, to alter the column, I need to do:

    ALTER TABLE Tags ALTER COLUMN Status tinyint NOT NULL;

    Another inconsistency in SQL. We don’t provide the whole definition again, and here we need to provide the column definition, even when only changing one of the settings.

  • Data Breach Danger

    Recently a court in the US ruled that there was no imminent danger from a data breach at a Texas hospital. This is good news and bad news for the world, and I’m a little torn about how I feel. On one hand, it’s good for us as data professionals that we aren’t necessarily going to be liable for the immediate effects from lost data. While the losses aren’t always our fault, we certainly could feel pressure from management if companies faced immediately legal or financial penalties.

    However it’s bad news because I think there’s little else that data breaches do than cause harm to those whose information is lost. It can be incredibly hard to link a specific breach to a specific identity theft incident, and I see this as a way of allowing companies to escape liability for their poor security practices.

    In reality, however, I have no solution to propose. As a data professional, I try to keep data safe, but it’s very, very difficult. One small hole in your technical infrastructure or human employees and you can lose a ton of data very, very quickly. I know it’s not lost, but copied, however you have lost control of it.

    We will face more and more security incidents, and as those tasked with protecting data, I’m not sure what we can do, or should do. However, I do think that organizations can’t take all responsibility, nor can they take no responsibility. The balance of how to deal with losses and issues is certainly something I hope we work out.

    Soon.

    Steve Jones