Detecing someone used /NOCOMMAND upon login

[Dave Lennon]

Hi,
Does anyone know of a way of detecting that a interactive process used the /NOCOMM qualifier to login (so that their personal LGICMD doesn't run), such as:
Username: USER/NOCOMMAND
Ideally, I would like to check for this in SYS$SYLOGIN with DCL, but a method to check other processes for this, such as using SDA would be very useful, as well.

Thanks,
Dave

[Lawrence Czlapinski]

Dave,
1. You can prevent changing of defaults for /disk /command or /lgicmd by setting /flags=restricted in AUTHORIZE.
2. Don't know of a way that you could detect someone using /NOCOMMAND.
Lawrence

[Doug Phillips]

If you have IMAGE enabled in accounting and the user login executes a specific image or a specific pattern of images, you would see that in the accounting report. i.e:

... LOGINOUT....username
... SET.........username
... APPINIT.....username

So, if you don't see your pattern, the user didn't execute the login.

The sys$manager:accountng.dat file can get big real fast on an active system, though.

Doug

[Ian Miller.]

individual images can be installed with accounting enabled. audit ACE can also be used but the problem is you would be looking for the absence of accessing a file.

What is the real problem you are trying to solve?

[John Gillings · Accepted solution]

Dave,

Tricky question! I *think* this is correct, but haven't been able to positively confirm it. It's also totally unsupported, so don't rely on it!

The field PPD$B_NPROCS in the Process Permanent Data (PPD) area is a count of the number of procedures to be executed during login. It includes SYLOGIN and LGICMD.

For a "normal" process the value of this byte will be 2, one that logged in with /NOCOMMAND will be 1.

From SDA, you can check this with:

SDA> SET PROCESS/INDEX=
SDA> EXAMINE CTL$AG_CLIDATA+1C

Look at the low byte of the longword. I haven't been able to find a place that PPD$B_NPROCS is defined in a distribution. The magic number for V7.2 and V7.3 is 28 (%X1C)

HOWEVER, note that you can't tell if they logged in with /COMMAND=some-other-file , *including* /COMMAND=NL: (which is exactly equivalent to /NOCOMMAND). So I guess it depends on how clever your users are!

From DCL we need to get into even deeper hackery. You can do this for the CURRENT process only. Also this is STRICTLY unsupported DCL hackery, so don't complain if it doesn't work, and don't use it in any critical code. No guarantees that it will work, or if it does, that it will continue to do so.

Step 1: This is VERSION DEPENDENT

Find the value of CTL$AG_CLIDATA for your specific version of OpenVMS (this one is for V7.3-2)

$ ANALYZE/SYSTEM
SDA> EVALUATE CTL$AG_CLIDATA
Hex = 00000000.7FFCDA60 Decimal = 214727740 CTL$AG_CLIDATA

Step 2: Store the value in a symbol

$ CTL$AG_CLIDATA = %X7FFCDA60

Now read the byte at offset 28 from that address:

$ DDP$B_PROCS=F$CVUI(0,8,-
F$FAO("!AD",1,CTL$AG_CLIDATA+28))

Symbol DDP$B_PROCS will be 1 is the process logged in with /NOPROCESS

[John Gillings]

Dave,

Aha!

Again unsupported, but perhaps a bit less so than hacking around in PPD structures. Much simpler, and version independent...

Login procedures are implemented by faking out the procedure call stack. When LOGINOUT exits, DCL "returns" to the first line in SYLOGIN and it appears that SYLOGIN was called from LGICMD, so when SYLOGIN exits, it returns to the first line of LGICMD (the mechanism is actually generic, so there could be many more procedures executed at login).

What this means is F$ENVIRONMENT("DEPTH") from SYLOGIN will tell you if there is an LGICMD to be executed.

If the user logs in with /NOCOMMAND, F$ENVIRONMENT("DEPTH") will be 1 from SYLOGIN. Otherwise it will be 2.

Same caveat as with PPD$B_NPROCS - we can't tell if the user logged in with /COMMAND=NL: or /COMMAND=other-proc


Back to hacking... here's some version dependent code that will traverse the DCL call stack. Executing this from SYLOGIN will find the name of LGICMD derived either from the UAF, or from the login /COMMAND qualifier.

Check values of the symbols in SDA, procedure assumes V7.3-2 (beware of wrapping)

SDA> READ DCLDEF
SDA> EVAL CTL$AG_CLIDATA
etc...

$ ctl$ag_clidata = %x7FFCDA60 ! From SYS.STB
$ ppd$l_prc = %x00000008 ! From DCLDEF.STB
$ idf_l_lnk = %x00000000 ! From DCLDEF.STB
$ idf_l_filename = %x00000068 ! From DCLDEF.STB
$ prc_l_idflnk = %x000000BC ! From DCLDEF.STB
$ prc = f$cvui(0,32,f$fao("!AD",4,ctl$ag_clidata+ppd$l_prc))
$ idf = f$cvui(0,32,f$fao("!AD",4,prc+prc_l_idflnk))
$ lev = f$environment("depth")
$ next:
$ if idf .eq. 0 then exit
$ write sys$output -
f$fao(" !2UL !AC",lev,-
f$cvui(0,32,f$fao("!AD",4,idf+idf_l_filename)))
$ idf = f$cvui(0,32,f$fao("!AD",4,idf+idf_l_lnk))
$ lev = lev - 1
$ goto next

[Wim Van den Wyngaert]

There is also a flag called DEFCLI that does less than RESTRICTED (e.g. control Y is not changed).

Wim

[Jan van den Ende]

Wim,

cf documentation that flag prevents choosing another CLI, but there is nothing about choosing another (or no) /COMM procedure! Have you tested it? Under 7.3-2 I can still use /NOCOMM with /FLAG=DEFCLI !


Cheers.

Have one on me.

Jan

[Jan van den Ende]

John,

is there a specific reason for the F$FAO documentation (up to and including V7.3-2) to specify that
"Two types of directives that are supported by $FAO system service are >>>> NOT <<<<< supported by the DCL F$FAO lexical function:
.
.
.
String directive other than the !AS directive ...."

where very obvious !AC and !AD are functioning?
Surely you did not mean THAT part of the procedure to be unsupported?

Perhaps a need for a DOC update?

Cheers.

Have one on me.

Jan

[Wim Van den Wyngaert]

Jan,

You're right. It's doing a lot less (why was it invented ?). But the tricky thing of RESTRICTED is that they disabled control_Y together with /command /disk and /cli. And if you are not the owner of the login.com file you can not simply re-enable it.

Have a Duvel on me (but not during working hours)

Wim

[Wim Van den Wyngaert]

In my black book (VMS Internals 5.2, p799) I read that there also exists DEC/Shell and CSHELL.

Does anyone knows where they live ?

Wim

[Ian Miller.]

Wim - those other CLIs where part of the POSIX layered product and long since expired.

John G - that's the sort of fun answer to encourage me to go and play :-) I expect you've been reading the listings again.

[Wim Van den Wyngaert]

Ian, Posix in 5.2 ?

[Wim Van den Wyngaert]

Does anyone remember when VMS became Open ?

Was it when POSIX was added ?

As POSIX is no longer supported, shouldn't it be ClosedVMS or VMS again ?

What was the last 4.x version ?

In any case, my 5.2 book is not called OpenVMS but VAX/VMS.

Wim (confused and having memory faults on memories that have been unused for 15 years)

[Jan van den Ende]

Wim,

first (visible) pieces of Posix added 5.4-2
renamed to OpenVMS 5.4-3
Last V4.x V4.7-A (or V4.7-H1), not sure which was later, nor if there have been other -H 's)
And V5.2 definitely was VMS, not OpenVMS

hth

Not sure yet about Duvel, I may get into (wheat-) Bokbier tonight.

Try one of those on me.

Cheers.

jpe

[Dave Lennon]

Thanks to John Gillings! That was exactly what I was looking for (and more).