4 Replies Latest reply on Mar 31, 2009 11:32 AM by Clebert Suconic

    SecurityChecks on Sends (AsyncSend & createProducer)

    Clebert Suconic Master


      Two questions:


      First: createProducer doesn't do any security checks, as there is nothing being created on Server for a producer, but shouldn't we do a round-trip just to validate security?


      Second: (Assuming createProducer would throw an exception if no-security):

      Say you are sending messages (Asynchronously), and you don't have sending permissions... (or you lost permissions after the createProducer). The serverSide will ignore the sends and will only log those errors.

      Shouldn't we save exceptions on Async operations, so the next time a Sync operation come (commit, prepare, close) we throw the pending exceptions?

      For instance: ATM if you don't have security privileges to send, Prepare is not failing.

      The following test is failing:

      prod = sendingSession.createProducer(addressA);
       prod.send(createTextMessage(sendingSession, "Test", true));
       prod.send(createTextMessage(sendingSession, "Test", true));
       sendingSession.end(xid, XAResource.TMSUCCESS);
      
       try
       {
       sendingSession.prepare(xid);
       fail("Exception was expected");
       }
       catch (Exception e)
       {
       e.printStackTrace();
       }
      
      




      I would expect the following test to also fail:


       prod = sendingSession.createProducer(addressA);
      
       securityManager.removeRole("auser", "guest"); // removing send privileges
      
       prod.send(createTextMessage(sendingSession, "Test", true)); // Async, ok.. I can accept not having a failure here.
       prod.send(createTextMessage(sendingSession, "Test", true)); // Async.. I can accept not having a failure here.
       try
       {
       sendingSession.close(); // The consumer had failures on Async operations.. should't close throw an exception?
       fail("Expected exception");
       }
       catch (MessagingException e)
       {
       e.printStackTrace();
       // I would expect the close to fail, since there were failures registered
       }
      
      


        • 1. Re: SecurityChecks on Sends (AsyncSend & createProducer)
          Andy Taylor Master

           

          First: createProducer doesn't do any security checks, as there is nothing being created on Server for a producer, but shouldn't we do a round-trip just to validate security?


          I don't think so, firstly the producer may be anonymous and since the checks are done by address you couldn't do it anyway. secondly, If you did do security checks there would be no point in checking on send. Lastly,

          Say you are sending messages (Asynchronously), and you don't have sending permissions... (or you lost permissions after the createProducer). The serverSide will ignore the sends and will only log those errors.


          I think thats ok, as long as its logged and if the user wants they can send blocking.

          Shouldn't we save exceptions on Async operations, so the next time a Sync operation come (commit, prepare, close) we throw the pending exceptions?


          i'm not sure that is a good idea. what if the next sync call was creating a consumer, it wouldn't make sense to throw an exception for a previous send. We probably should mark a tx as rollback only tho', which I'm not sure we do.

          • 2. Re: SecurityChecks on Sends (AsyncSend & createProducer)
            Tim Fox Master

            Under the new security model, the same permission is required for creating a producer (non anon) as for sending to an address.

            So the check on create producer seems redundant.

            • 3. Re: SecurityChecks on Sends (AsyncSend & createProducer)
              Tim Fox Master

              Actually it's a jms requirement to check if dest exists on send.

              In any case, I have fixed the code so the test now passes.

              • 4. Re: SecurityChecks on Sends (AsyncSend & createProducer)
                Clebert Suconic Master

                What about Consumers?

                We only check for security on Createconsumer.

                If we create a Consumer, and remove the Security attribute, we can keep receiving messages on the destination as long as we keep that Consumer opened.

                Is that the expected behaviour from the user's (admin) perspective?