topic Re: Find process by assumed persona in Operating System - OpenVMS

Find process by assumed persona

Graham Burley — Sat, 24 May 2008 09:35:51 GMT

A program uses SYS$PERSONA_ASSUME to a persona obtained from SYS$ACMW. The process displays the assumed identity in SHOW PROCESS,F$GETJPI etc, but you can't find the process using the assumed identity.

E.g. with SHOW SYSTEM -

$ sh sys/proc=*nn*/fu
OpenVMS V8.3 on node EISNER 24-MAY-2008 05:03:57.73 Uptime 132 13:33:44
AlphaServer DS20 500 MHz
Pid Process Name State Pri I/O CPU Page flts Pages
0005B853 LEF 5 51 0 00:00:00.02 155 186
[SUPPORT,BURLEY] 1488Kb

$ sh sys/own=burley/fu
OpenVMS V8.3 on node EISNER 24-MAY-2008 05:04:07.95 Uptime 132 13:33:54
AlphaServer DS20 500 MHz
Pid Process Name State Pri I/O CPU Page flts Pages
0008663B BURLEY CUR 0 5 6568 0 00:00:01.72 4375 141
[SUPPORT,BURLEY] 1128Kb

$ sho sys/id=0005B853/fu
OpenVMS V8.3 on node EISNER 24-MAY-2008 05:04:27.56 Uptime 132 13:34:14
AlphaServer DS20 500 MHz
Pid Process Name State Pri I/O CPU Page flts Pages
0005B853 LEF 5 51 0 00:00:00.02 155 186
[SUPPORT,BURLEY] 1488Kb

Also can't find it with F$CONTEXT + F$PID -

$ ctx=""
$ tmp=f$context("PROCESS", ctx, "USERNAME", "BURLEY" ,"EQL")
$ write sys$output f$pid(ctx)
0008663B
$ write sys$output f$pid(ctx)

$

Re: Find process by assumed persona

John Gillings — Sun, 25 May 2008 21:09:20 GMT

Graham,

Have you tried F$CONTEXT with UIC?

Your SHOW SYSTEM of the assumptive process is displaying a UIC, not a Username.

OpenVMS can be a bit schizophrenic when it comes to UICs and Usernames. As you're no doubt aware, they're not really connected.

Compare F$GETJPI USERNAME and UIC before and after assuming the persona.

Re: Find process by assumed persona

Graham Burley — Sun, 25 May 2008 22:57:50 GMT

> Have you tried F$CONTEXT with UIC?

Same result.

> Compare F$GETJPI USERNAME and UIC before and after
> assuming the persona.

$ sh sys/proc=*nn*
OpenVMS V8.3 on node EISNER 25-MAY-2008 17:51:08.72 Uptime 134 02:20:44
Pid Process Name State Pri I/O CPU Page flts Pages
00014881 LEF 5 30 0 00:00:00.04 138 169
$ write sys$output f$getjpi("00014881","USERNAME")
SYSTEM
$ write sys$output f$getjpi("00014881","UIC")
[SYSTEM]

And after:

$ write sys$output f$getjpi("00014881","USERNAME")
BURLEY
$ write sys$output f$getjpi("00014881","UIC")
[SUPPORT,BURLEY]

Both SHOW SYSTEM and F$CONTEXT + F$PID return the process under the original/natural persona rather than the assumed one.

Re: Find process by assumed persona

Wim Van den Wyngaert — Mon, 26 May 2008 08:49:45 GMT

I know nothing but ana/sys has show proc/persona. May be a script around this can solve your problem.

Wim

Re: Find process by assumed persona

Richard J Maher — Mon, 26 May 2008 22:14:25 GMT

Hi Graham,

That's amazing! As long as you have privs (group,world, etc) to see the new UIC (whick clearly you do for the PID access methos) then I say "bug". Has anyone got the source code to check?

It's hardly likely to be a DCL quirk, but has anyone tried with a 3GL SYS$GETJPI?

I'll have a ho tonight if no one can shed any further light on it.

Cheers Richard.

Re: Find process by assumed persona

John Gillings — Tue, 27 May 2008 00:43:26 GMT

Interesting!

F$CONTEXT creates an internal item list using $PROCESS_SCAN. Looking at the SSRM and $PSCANDEF, there's nothing about personas. I suspect it hasn't been updated to deal with personas, and is looking at the "permanent" fields for username and UIC. The SSRM contains the note:

"The item codes referenced by $PROCESS_SCAN are found in data structures that are always resident in the system, primarily the process control block (PCB) and the job information block (JIB). A scan of processes never forces a process that is swapped out of memory to be brought into memory to read nonresident information."

This may be one reason for Graham's observation (another might be that no one has ever asked!), are the persona structures permanently resident?

On the other hand, $GETJPI knows all about personas, and is not constrained to avoid swapping processes into memory.

The big question is how should process scan operate? Should it see the "real" username, or the persona? Should there be an option to request one or other explicitly? What about the default?

Maybe it's all just "too hard"? After all, you could implement what you want by looping across all processes and performing your own matches against username or UIC (or, for that matter any of the JPI$_PERSONA* items).

I'm undecided if I agree with Richard that this is a bug. I could probably be convinced either way.

If you care enough, please log a case against a support contract and request an enhancement (or bug fix). Unless someone asks, it will stay as it is.

Re: Find process by assumed persona

Jon Pinkley — Tue, 27 May 2008 07:00:19 GMT

Graham,

If the intent is to permanently change the values, I have been able to modify the ACCOUNT with $persona_modify, specifying "-1" for the persona to modify. "-1" is the natural persona.

I am attaching a Fortran function that does this. We've been using it from a program that changes the account name whenever someone changes his or her working "environment" (a set of logical names controlling which devices/files will be used). This allows us to see what "environment" was in effect at the time an image was run, and this is a field that shows up in the image accounting records, but has little affect on anything else.

I would expect that anything that can be changed in an assumed persona can be modified in the natural persona. If you aren't switching between multiple personae, then I would just modify the natural persona and be done.

Jon

P.S. I also sent the source to your Eisner account.

Re: Find process by assumed persona

Graham Burley — Tue, 27 May 2008 23:04:18 GMT

In the case of a multi-threaded server switching between many personas using the natural persona in process scan may make sense, but it does seem incredibly inconsistent to have a utility like show system using different personas for display and selection purposes.

I hadn't considered using SYS$PROCESS_MODIFY, but if it's intended to work that way it'd be more appropriate to the single persona switch required. My impression was that modify was to be used on a persona that was then assumed, not an active one.

Re: Find process by assumed persona

Richard J Maher — Wed, 28 May 2008 11:36:42 GMT

Hi Graham,

Sorry I didn't get back to you last night. (My PAKs ran out and I was knackered, and sadly the results of my efforts won't help you much anyway - code below FWIW)

Basically, it's still bollocks with $getjpi in a 3GL :-( Why VMS engineering wouldn't be all over this like the IMM team on a free-meal, I have no idea. (FWIW, you get the old Username when you do a Conttrol-T as well)

I'm sick of arguing with people and I'm not sure if John still thinks it's unsupported to do a $persona_assume followed by a $creprc (VMSNOTES circa 1995) but as you rightly pointed out the issue of consistency is the one that simply cannot be avoided!

That's on Alpha BTW, maybe it's different on VAX?

Cheers Richard Maher

PS. PAKs are no free for DSPP memebers! Yippee! I used to think 250 quid was a bargain anyway, but this is even better :-)

getjpi.cob
identification division.
program-id. getjpi with ident "V1.0".
data division.
working-storage section.
01 ss$_nomoreproc pic s9(9) comp value external ss$_nomoreproc.
01 ss$_normal pic s9(9) comp value external ss$_normal.
01 sys_status pic s9(9) comp.
*
01 pidctx pic s9(9) comp.
01 scan_list.
03 item_nodename.
05 pic s9(4) comp value 1.
05 pic s9(4) comp value external pscan$_nodename.
05 pointer value reference wildcard.
05 pic s9(9) comp value external pscan$m_wildcard.
03 item_username.
05 search_username_len pic s9(4) comp.
05 pic s9(4) comp value external pscan$_username.
05 pointer value reference search_username.
05 pic s9(9) comp.
03 pic s9(9) comp.
*
01 wildcard pic x(1) value "*".
01 search_username pic x(12).
*
01 jpi_list.
03 item_pid.
05 pic s9(4) comp value 4.
05 pic s9(4) comp value external jpi$_pid.
05 pointer value reference pid.
05 pic s9(9) comp.
03 item_prcnam.
05 pic s9(4) comp value 11.
05 pic s9(4) comp value external jpi$_prcnam.
05 pointer value reference out_prcnam.
05 pointer value reference out_prcnam_len.
03 item_nodame.
05 pic s9(4) comp value 6.
05 pic s9(4) comp value external jpi$_nodename.
05 pointer value reference nodename.
05 pointer value reference nodename_len.
03 pic s9(9) comp.
*
01 iosb.
03 cond_val pic s9(9) comp.
03 pic s9(9) comp.
01 pid pic s9(9) comp.
01 out_prcnam pic x(15).
01 out_prcnam_len pic 9(4) comp.
01 nodename pic x(6).
01 nodename_len pic 9(4) comp.
*
procedure division.
kick_off section.
00.
display "Enter username to search for : " no advancing erase screen.
accept search_username protected size 12 editing reversed bold at end go to fini.

call "str$trim"
using by descriptor search_username, search_username
by reference search_username_len
giving sys_status.
if sys_status not = ss$_normal call "lib$stop" using by value sys_status.
if search_username_len = zeros go to fini.

call "sys$process_scan" using pidctx, scan_list giving sys_status.
if sys_status not = ss$_normal call "lib$stop" using by value sys_status.

call "sys$getjpiw" using omitted, pidctx, omitted, jpi_list, iosb, omitted, omitted giving sys_status.
if sys_status = ss$_normal move cond_val to sys_status.
if sys_status not = ss$_normal call "lib$stop" using by value sys_status.

perform search_loop until sys_status not = ss$_normal.
if sys_status not = ss$_nomoreproc
call "sys$process_scan" using pidctx, omitted giving sys_status
if sys_status not = ss$_normal call "lib$stop" using by value sys_status.
*
fini.
stop run.
*
search_loop section.
00.
display "Process Name: ", out_prcnam(1:out_prcnam_len).
display "pid = ", pid with conversion.
*
call "sys$getjpiw" using omitted, pidctx, omitted, jpi_list, iosb, omitted, omitted giving sys_status.
if sys_status = ss$_normal move cond_val to sys_status.
if sys_status not = ss$_normal and ss$_nomoreproc
call "lib$stop" using by value sys_status.
*
end program getjpi.

become.cob
identification division.
program-id. become with ident "V1.0".
data division.
working-storage section.
01 crepsn_flags pic s9(9) comp value external crepsn_flags.
01 asmpsn_flags pic s9(9) comp value external asmpsn_flags.
01 ss$_nomoreproc pic s9(9) comp value external ss$_nomoreproc.
01 ss$_normal pic s9(9) comp value external ss$_normal.
01 sys_status pic s9(9) comp.
*
01 creprc_persona pic 9(9) comp.
01 restore_persona pic 9(9) comp value 1.
*
01 jpi_list.
03 item_pid.
05 pic s9(4) comp value 4.
05 pic s9(4) comp value external jpi$_pid.
05 pointer value reference pid.
05 pic s9(9) comp.
03 item_username.
05 pic s9(4) comp value 11.
05 pic s9(4) comp value external jpi$_username.
05 pointer value reference out_username.
05 pointer value reference out_username_len.
03 pic s9(9) comp.
*
01 iosb.
03 cond_val pic s9(9) comp.
03 pic s9(9) comp.
01 pid pic s9(9) comp.
01 in_username pic x(12).
01 in_username_len pic 9(4) comp.
01 out_username pic x(12).
01 out_username_len pic 9(4) comp.
*
procedure division.
kick_off section.
00.
display "Who to become: " no advancing erase screen.
accept in_username protected size 12 editing reversed bold at end go to fini.

call "str$trim"
using by descriptor in_username, in_username
by reference in_username_len
giving sys_status.
if sys_status not = ss$_normal call "lib$stop" using by value sys_status.
if in_username_len = zeros go to fini.

call "sys$persona_create"
using by reference creprc_persona
by descriptor in_username(1:in_username_len)
by value crepsn_flags
giving sys_status.
if sys_status not = ss$_normal call "lib$stop" using by value sys_status.

call "sys$persona_assume"
using by reference creprc_persona
by value asmpsn_flags
giving sys_status.
if sys_status not = ss$_normal call "lib$stop" using by value sys_status.
*
call "sys$getjpiw" using omitted, omitted, omitted, jpi_list, iosb, omitted, omitted giving sys_status.
if sys_status = ss$_normal move cond_val to sys_status.
if sys_status not = ss$_normal and ss$_nomoreproc call "lib$stop" using by value sys_status.

display "We are now [", out_username(1:out_username_len), "]".
display "Press return when finished. . ." no advancing.
accept in_username.

call "sys$persona_assume"
using by reference restore_persona
by value asmpsn_flags
giving sys_status.
if sys_status not = ss$_normal call "lib$stop" using by value sys_status.

call "sys$persona_delete" using creprc_persona giving sys_status.
if sys_status not = ss$_normal call "lib$stop" using by value sys_status.
*
fini.
stop run.
*
end program become.

getjpi_def.mar
.title GETJPI_DEF - External data

$impdef GLOBAL

.library /sys$library:lib.mlb/

$pscandef GLOBAL

crepsn_flags ==
asmpsn_flags ==

.end

Re: Find process by assumed persona

Graham Burley — Wed, 28 May 2008 17:22:52 GMT

> (FWIW, you get the old Username when you do a Conttrol-T as well)

That's the process name. There's lots of things persona services don't do, but setting the process name is not top of my wishlist.

Re: Find process by assumed persona

Hoff — Wed, 28 May 2008 17:53:09 GMT

While I understand the immediate sequence and commands and the particular problem encountered (multiple-persona disorders often are), what application or problem are you looking to address here?

By backing up a step or three, there may well be another and different way to address the problem here.

I do see this is involving the Notes NNTP gateway.

Re: Find process by assumed persona

Richard J Maher — Thu, 29 May 2008 09:40:10 GMT

Hi Graham,

>> (FWIW, you get the old Username when you
>> do a Conttrol-T as well)

>That's the process name. There's lots of
> things persona services don't do, but
> setting the process name is not top of my
> wishlist.

Doh! Yeah, sorry for pointless, useless, and in all other senses just wrong observation. My mind's still stuck on polling for the magical appearance of an ETicket Number in a labyrinth of XML :-( Modern technology eh?

Anyway, I'm going to repost the same code as an attachment here as I feel it illustrates the bug you've identified nicely. (If not for you then maybe for someone else)

FWIW, I'll post a slight variation of the code that might help you as a work-around. (If a "work-around" is in fact what you're after?)

Basically, it drops the username-equality from the $process_scan an shifts the responsibility to your code. IE. Even though $process_scan couldn't see the persona Username, the subsequent $getjpi returns the *correct* username and then you manually filter out the ones you want. (At least I think it does, I'll post the code anyway in a minute)

Cheers Richard

PS. Is there a control-t like thing on Linux?

Re: Find process by assumed persona

Richard J Maher — Thu, 29 May 2008 10:01:10 GMT

OK, here 'tis,

Not much changed, but as discussed the filtering is done in your code rather than the (blatantly buggy) $process_scan.

I haven't ruled out other options, if what I think the code is doing is not correct, or not what you want.

If only it was Web Services or a Unix semaphore then $process_scan might get fixed :-( And if it was related to DECWindows or PCSI related then there'd be no trouble getting it back-ported.

Cheers Richard

PS. Now where was I? Oh yes, if nestedClass.getUseless().getContruct().getLongFreeText.indexOf("Pax1") - or was it List before that?

Re: Find process by assumed persona

labadie_1 — Thu, 29 May 2008 10:04:56 GMT

Graham, I am sorry, this is out of the subject of your post

>>>PS. Is there a control-t like thing on Linux?

Well Control-T is just SIGINFO, and by the way, yes, with Linux, some tools have it, like

dd, fsck, dump, cp, tcpdump, tethereal, tshark
(and I guess many others)

Bsd And Vms have had Control T for a long time (from day one ?)
And Mac OS X 10.4 has it
http://www.macosxhints.com/article.php?story=200505201204071(...)

Somebody offered in the
Linux Kernel Mailing List to add it for the kernel 2.4, but it has not been added
http://www.cs.tau.ac.il/~didi/ctrl-t/

Re: Find process by assumed persona

Graham Burley — Thu, 29 May 2008 15:04:14 GMT

> what application or problem are you looking to address here?

I was doing some simple DCL to see if a user active on the system when I noticed that these processes were not included. I can work around that, but was curious about the behaviour, and whether I was missing/messing up something in the persona calls.

I'm not likely to log a support case about this. I'm not sure how $PROCESS_SCAN should be amended to cope with personas, but the current behaviour looks a bit odd to me.

Thanks to all who responded, in particular John Gillings re $PROCESS_SCAN and persona issues.

Re: Find process by assumed persona

Graham Burley — Thu, 29 May 2008 15:14:18 GMT

See previous note.

Re: Find process by assumed persona

Richard J Maher — Fri, 30 May 2008 11:01:56 GMT

Hi Graham,

I've just re-read this thread and realized that John came up with the application-side filtering idea about 3 weeks ago; therefore I have concluded that my contribution to the debate has been about zero (except perhaps for that certain je ne sais quoi that only I can bring :-)

I'm replying now only 'cos you've helped me a lot recently and I so desperately wanted to reciprocate, and I haven't felt this useless and ineffectual since about, well, yesterday.

On the plus side, John's (Hoff's?) persuit of a security fix for the dodgy lib$get_vm call in sys$persona_create, may have left the crack open for an inclusion of a $process_scan fix on the same cost-code? (Or an inner-mode safe lib$*vm heap manager would obviously be better!)

Anyway, in my quest for relevance, I've attached some kernel mode code that I used to use before DEC gave us the lovely the persona services - last working circa VAX/VMS 6.2. (I can't see the working-set lock-down which is ringing alarm bells and I am by no means recommending that anyone use this in production!)

On a closing note, you mentioned a $persona* wish list? I happen to think the persona services are the mutt's nuts! Ask away!

How 'bout a starter question? "West Sussex pubs for $10"? European -vs- African Swallows? My favourite colour? It's Tourquoise! Ask fancy-pants Gillings if he knew that then eh :-)

Cheers Richard