MessageQueue.CanWrite always returns true
Asked Answered
S

1

6

I have deselected the permissions for Send Message on a private queue, yet MessageQueue.CanWrite never returns false. I can toggle Receive Message permissions and the CanRead property responds as expected. Why would the CanWrite property behave differently?

I have tested this issue with a couple of different AD users and the results are the same.

Is there a different approach to validating whether a specific user account can send a mesage to a specific remote private queue?

public class SendBehavior : IMsmqRuleBehavior
{
    public bool Validate(string queuePath)
    {
        using (var queue = new MessageQueue(queuePath, QueueAccessMode.Send))
        {
            return queue.CanWrite;                                        
        }
    }
}

public class ReceiveBehavior : IMsmqRuleBehavior
{
    public bool Validate(string queuePath)
    {
        using (var queue = new MessageQueue(queuePath, QueueAccessMode.Receive))
        {
            return queue.CanRead;                
        }
    }
}
Suboceanic answered 5/8, 2013 at 19:4 Comment(5)
It seems that if QueueAccessMode.Send is requested that CanWrite would likely be true. (side question: did you toggle the 'Authenticated` check box for this queue)Tinny
I considered that but the default QueueAccessMode is SendAndReceive and the CanRead test behaves as expected with the QueueAccessMode set to Receive.Suboceanic
Does CanWrite become false when you set QueueAccessMode.Receive? Because from my review of the MessageQueue class in ILSpy it seems that only your modes you give reflect those property values.Tinny
Also, does it fail when you send a message? It appears this would be key to determining if this is the expected behavior.Tinny
The Authenticated checkbox was not checked. It is now and there was no change in behavior.Suboceanic
T
3

From what I can tell, this behavior is as intended for MessageQueue.CanWrite. If you delve deep enough into the guts of the MessageQueue class, you'll find it creates some helper objects which influence the value of this property in the following manner:

  1. If you pass QueueAccessMode.Send (or SendAndReceive), an internal access mode helper will be created which returns true if (this.accessMode & QueueAccessMode.Send) != (QueueAccessMode)0.

  2. If #1 is true, it then attempts to open the queue to store it into the cache, using the access mode and sharing you have requested. At this point a call to the native method MQOpenQueue is made, which has the following in its remarks (emphasis mine):

    If the access rights for opening the queue in the mode requested are not allowed for the calling application, the following two things can happen:

    • If dwAccess is set to MQ_SEND_ACCESS, MQOpenQueue will succeed, but errors will be returned when the application tries to send a message.
    • If dwAccess is set to MQ_PEEK_ACCESS or MQ_RECEIVE_ACCESS, MQOpenQueue will fail and return MQ_ERROR_ACCESS_DENIED (0xC00E0025). In this case a queue handle is not returned to phQueue.

Therefore, given a QueueAccessMode.Send (or SendAndReceive) with a valid queue name and sharing mode, it is my understanding that CanWrite will return true, even if you truly do not have access to send a message.

Basically it appears that you will only receive CanWrite == false if and only if:

  1. You pass a QueueAccessMode which is not Send or SendAndReceive.
Tinny answered 5/8, 2013 at 19:42 Comment(3)
Thanks for digging into this. Why would toggling the Receive Message permissions on the queue result in a true/false toggle of the "CanRead" property and when I send a message to the queue, with Send disabled, the message never makes it to the queue but I'm not receiving an exception either. That seems strange to me. I would think that CanRead and CanWrite would behave in the same manner.Suboceanic
@ChadLazette: I wish I had a better answer for you, but from what I can see this behavior is not based on the real permissions of the queue on the other end.Tinny
Fair enough. I appreciate it. I'll have to come up with another way to verify whether a user can send a message.Suboceanic

© 2022 - 2024 — McMap. All rights reserved.