Skip to Content

Since ASE 15.7 it’s possible to create stored procedures with option “execute as owner”

Which is quite a nice feature, e.g. to allow a user to unlock a login without having sso_role, you simply create a procedure like this

create procedure sp__locklogin  @login  varchar(30) = null, @action varchar(10) = null

with execute as owner

as  exec sp_locklogin @login, @action

Normally you would use the sa login to create this procedure in sybsystemprocs and grant execute permissions to a user defined role.

Grant the user defined role to a login, and that login can lock or unlock any other login wihout having sso_role

However, this feature presented a big security loop hole….

Just having a dbo alias in database sybsystemprocs allows you to create any procedure with execute as owner and executing it as the sa login, e.g.

create procedure sp_myproc  @cmd varchar(500)

with execute as owner

as  exec (@cmd)

With the latest patch level SP136 for ASE 15.7 (and latest patch level for 16.0) this security hole has been partly fixed. (See KB 2202914)

When impersonating the database owner, via a dbo alias or via setuser, it’s not possible anymore to refer to objects outside of the database when using option “with execute as owner”. Instead you’ll have to create the object with the database owner itself.

(Creating the proc sp_myproc, executing any SQL statement as login sa, is still allowed)

Example of what will fail

use a login having sa_role (not sa), which gets dbo alias in sybsystemprocs

create proc sp__listen

with execute as owner

as select * from master..syslisteners

go

Msg 16367, Level 16, State 1:

Server ‘ASE157’, Procedure ‘sp__listen’, Line 1:

EXECUTE AS OWNER procedures cannot be created by an alias or with the SETUSER command when the procedure has SQL statements hat reference objects across databases. Create the procedure from a non-impersonated session.

The only way to get this procedure created is using the sa login itself.

(Of course the same result can be achieved by executing sp_listener from sp__listen, but that’s not the point)

Error 16367 is also produced at other times, e.g. when running installmaster.

This must be executed using the sa login, because several procedures for sp_sysmon rely on this feature (KB 2183652) and can now only be installed by sa

In many environments the sa login is locked out for security reasons

Do you want to unlock the sa login just to deploy a stored procedure in sybsystemprocs?

To report this post you need to login first.

Be the first to leave a comment

You must be Logged on to comment or reply to a post.

Leave a Reply