How can I pick up the conversation_id of a message just sent or received?

Question

This answer says:

There is a conversation_id, which is the same at both endpoints.

And there is conversation_handle, which must be different at each endpoint.

So I thought it would be useful for troubleshooting to write the conversation_id to an audit table at each endpoint of a conversation. That way I could easily track down the audit information at each endpoint for a given conversation.

The problem is where to pick up the conversation_id from. I had originally thought I could look it up from sys.conversation_endpoints against the conversation_handle of the message just sent or received. However, the database users that send and receive messages do not have permissions to see the metadata in sys.conversation_endpoints.

I could get around that by making the users sending and receiving messages database owners but I would prefer not to for security reasons. What are the minimum permissions they would need to see the records in sys.conversation_endpoints? Alternatively, how else could I read the conversation_id of a message that had just been sent or received (from the code doing the sending or receiving, which would not have dbo or sysadmin permissions)?

Edit: I read the Books Online article about Metadata Visibility Configuration which states

the visibility of metadata is limited to securables that a user either owns or on which the user has been granted some permission

For catalog views such as sys.tables or sys.procedures it's fairly obvious what the securables are that the user needs to be granted permission to. But what are the securables listed in sys.conversation_endpoints: conversations, conversation endpoints? And how do you grant permissions to them? The user already has permission to begin a dialog or end a conversation so I would have thought it would already have adequate permission on a conversation.

Answer 1

The best place to get it is from sys.conversation_endpoints.

Whenever you are faced with the issue that your application requires privileges not held by the current user the best option is to leverage code signing. SQL Server allows an administrator to inspect and sign stored procedures, using certificates, and grant permissions to the signature. This allows an user to invoke the procedure and the procedure can access information not directly accessible to the user.

See signing Activated Procedures for an example.

As to why you can't see your own conversations: imho it's a bug. Running sp_helptext 'sys.conversation_endpoints' shows the permissions filter applied:

 CREATE VIEW sys.conversation_endpoints AS
SELECT ce.conversation_handle,
    ...
    FROM sys.conversation_endpoints$ ce
LEFT JOIN sys.syssingleobjrefs f 
      ON f.depid = ce.service_id 
      AND f.class = 21 
      AND f.depsubid = 0 -- SRC_SVCTOQUEUE
WHERE has_access('CO', f.indepid) = 1

The view shows conversations for which the user has CONTROL access over the queue of the service to which the dialog belongs (it takes some know-how about syssingleobjrefs to understand what the view condition is, but that what it translates to). The permission check should be for RECEIVE permission, because that is the permission required to BEGIN DIALOG/SEND/END messages on this service:

To begin a dialog, the current user must have RECEIVE permission on the queue for the service specified in the FROM clause of the command and REFERENCES permission for the contract specified
To send a message, the current user must have RECEIVE permission on the queue of every service that sends the message.

The MSND is actually wrong on the topic of END CONVERSATION permissions when it says 'To end an active conversation, the current user must be the owner of the conversation, a member of the sysadmin fixed server role or a member of the db_owner fixed database role'. The required permission is the same as one for SEND (this can be easily tested).

It can be easily argued that if you can manipulate a securable (and SEND, END are clearly manipulating conversations) then one should be able to see the metadata of the securable being manipulated.