15-Dec-2009

Queue management weirdness

This is weird. I was trying to come up with a way to let specific users use SMTP to send email off a box, and I thought "ah, there's a generic queue, and an execution queue. I can just modify the protection of the execution queue, and add an ACL for the users I want to allow email access."

So I set up a test:


$ write sys$output f$getsyi("arch_name") + " " + f$getsyi("version")
IA64 V8.3-1H1
$ init/que/batch/start test_exe_q/prot=(s:m,o:d,g:r,w:r)/own=system
$ init/que/batch/generic=test_exe_q/start test_gen_q/own=system
$ set acl/obj=que/acl=(ident=[*,*],access=none)
$ sh que/full test_*_q
Batch queue TEST_EXE_Q, idle, on xxxxxx::
  /BASE_PRIORITY=4 /JOB_LIMIT=1 /OWNER=[SYSTEM] /PROTECTION=(S:M,O:D,G:R,W:R)
         (IDENTIFIER=[*,*],ACCESS=NONE)

Generic batch queue TEST_GEN_Q
  /GENERIC=(TEST_EXE_Q) /OWNER=[SYSTEM] /PROTECTION=(S:M,O:D,G:R,W:S)
$

Obviously, I had privileges when I did this. Note that the execution queue has no world submit, and anyway, the ACL should block anything from using the queue (with the exception of someone holding BYPASS or SYSPRV privileges).

Next, I went and disabled my privileges with authorize. My default privilege mask consisted of TMPMBX and NETMBX.

Thinking "OK, now to test this", I submitted a batch job, expecting it to hang in the generic queue. To my utter surprise, it executed. What was going on here? I'd assumed (yes, I know what assume stands for, that's why I was doing a test) that the queue manager software would look at the system authorization file and rightslist to determine access before moving the batch queue entry from the generic queue to the execution queue, but apparently not. I can only guess that some smart programmer coded a check to see if the submitting process was still there, and grabbed the privilege mask from the submitting process as an I/O optimization.

When I logged the submitting process out, then logged back in, everything worked as I expected it to in the first place.

Weird, non-intuitive behaviour.

Posted at December 15, 2009 3:30 PM
Comments

It's not as weird as it seems:
First, changing privs in the UAF won't change the privileges of the running process. So if you have SYSPRV set, it will remain so if you remove it in UAF.
Seecond, IIRC, SUBMIT will check the credentials and privileges of the running process from P1 space, and will use these to access the queue to schedule the job. If that succeeds, once scheduled, the same privs will be used running the procedure.

Posted by: SYSMGR at December 17, 2009 7:08 AM

Obviously changing privs in the UAF won't change the privs of the running process.

And yes, SUBMIT checks the privs of the process submitting the job. However, once the job reaches the generic queue, it's a submitted batch job, and I would have though it would have been treated like one.

The job controller is responsible for moving the entry in the generic queue to the execution queue. This could happen seconds or months after the job was originally submitted. Where should the job look for the privs to test it can move the job to the execution queue? I would have thought the UAF every time.

The point is that it appears to grab the priv mask from the submitting job if the submitting job is still in existance. I would have never suspected that that would have happened.

Posted by: Jim Duff at December 17, 2009 8:03 AM

Comments are closed