InstantForum.NET v2.9.0SQLServerCentralhttp://www.sqlservercentral.com/Forums/notifications@sqlservercentral.comSat, 18 May 2013 11:13:14 GMT20http://www.sqlservercentral.com/Forums/Topic1396819-391-1.aspxOkay, again, so much clarity in hindsight.I also see another source of my confusion. Apparently, a stored proc is owned by whoever owns the schema it is in, by default, unless its specifically changed via ALTER AUTHORIZATION. So while schema != owner, the schema owner IS the procedure owner, unless it's been specifically changed. In my case, I'm seeing sa run these things because the proc is in the dbo schema, and the dbo schema is owned by dbo. I guess dbo = sa when it translates to login.More info on [url=http://www.sqlservercentral.com/blogs/brian_kelley/2009/03/04/owning-an-object-in-sql-server-2005-2008/]default ownership[/url]:Tue, 18 Dec 2012 09:13:47 GMTllevityhttp://www.sqlservercentral.com/Forums/Topic1396819-391-1.aspxSchema != ownerThat proc is old (pre SQL 2005) and hence changing schema and owner, before SQL 2005 they were the same thing. Use ALTER AUTHORIZATION to change owner and ALTER SCHEMA to move a table to a new schema.Books Online:[quote][b]sp_changeobjectowner[/b]Changes the owner of an object in the current database.Important: This stored procedure only works with the objects available in Microsoft SQL Server 2000. This feature will be removed in a future version of Microsoft SQL Server. Avoid using this feature in new development work, and plan to modify applications that currently use this feature. Use ALTER SCHEMA or ALTER AUTHORIZATION instead. [b]sp_changeobjectowner changes both the schema and the owner.[/b] To preserve compatibility with earlier versions of SQL Server, this stored procedure will only change object owners when both the current owner and the new owner own schemas that have the same name as their database user names. [/quote]Tue, 18 Dec 2012 08:55:23 GMTGilaMonsterhttp://www.sqlservercentral.com/Forums/Topic1396819-391-1.aspxAnother thing to file in my "bad assumptions" filing cabinet.Another question, then. When I change the object owner of the proc via sp_changeobjectowner, it changes the schema from dbo to the new owner I specify. Is this a case where schema and owner are the same thing? And this EXECUTE AS OWNER proc is running as sa because it's in the dbo schema?Tue, 18 Dec 2012 08:42:06 GMTllevityhttp://www.sqlservercentral.com/Forums/Topic1396819-391-1.aspx[quote][b]llevity (12/18/2012)[/b][hr]The procs were set to EXECUTE AS OWNER, and the database was owned by sa in our QA environment. Thanks a ton![/quote]Execute as owner does not use the database owner, it uses the procedure owner. Means a sysadmin created the procedures, that's all.Tue, 18 Dec 2012 08:25:14 GMTGilaMonsterhttp://www.sqlservercentral.com/Forums/Topic1396819-391-1.aspxAaaaah, thanks guys. I feel so dumb now. Why are these things always so obvious in hindsight?The procs were set to EXECUTE AS OWNER, and the database was owned by sa in our QA environment. Thanks a ton!Tue, 18 Dec 2012 08:00:25 GMTllevityhttp://www.sqlservercentral.com/Forums/Topic1396819-391-1.aspxImpersonation? Got procs with EXECUTE AS 'sa' in them?Tue, 18 Dec 2012 07:52:07 GMTGilaMonsterhttp://www.sqlservercentral.com/Forums/Topic1396819-391-1.aspxDo the procs have the EXECUTE AS clause to let them run under higher privileged accounts?Tue, 18 Dec 2012 07:51:52 GMTanthony.greenhttp://www.sqlservercentral.com/Forums/Topic1396819-391-1.aspxThey're not system processes, though. I see a NTUserName associated with the process and they're executing user stored procs called from a web app.Tue, 18 Dec 2012 07:45:57 GMTllevityhttp://www.sqlservercentral.com/Forums/Topic1396819-391-1.aspxSystem processes are no longer limited to SPID < 50 they can go over 50 depending on the task they perform.Tue, 18 Dec 2012 07:04:34 GMTanthony.greenhttp://www.sqlservercentral.com/Forums/Topic1396819-391-1.aspx'sa' account is the default sql admin user and all system processes 'below spid 50' uses saRegardsTue, 18 Dec 2012 07:03:13 GMTNchax Phokuhttp://www.sqlservercentral.com/Forums/Topic1396819-391-1.aspxAs the subject says, I have a profiler running and see some things executing as 'sa' in the LoginName field, but 'sa' on the server is disabled. I even changed its password.These aren't system level processes, as the NTUserName is an actual user, who is using the application that connects to the database on our dev environment. Any ideas on what's going on?Fri, 14 Dec 2012 14:27:42 GMTllevity