Access violation message in operator.log

[Fredrik.eriksson]

Hi,

I've had these for quite a while, but never really taken time to figure them out. Now that I had some time over I thought I'd investigate it. But I'm stumped.

%%%%%%%%%%% OPCOM 28-JUN-2009 02:12:37.32 %%%%%%%%%%%
Message from user SYSTEM on NODE1
Event: Access Control Violation from: Node LOCAL:.NODE1 Session Control,
at: 2009-06-28-00:12:37.320+00:00Iinf
NSAP Address=39:752:01-00-00-00-00-00-00-05-00-0A:AA-00-04-00-07-28:20,
Source=UIC = [0,0]ARESCHOUG_B,
Destination=number = 17,
Destination User="",
Destination Account="",
Node Name=LOCAL:.UGGLA
eventUid 26602FC1-6389-11DE-B273-4241534E4731
entityUid C7765974-60F5-11DE-8405-AA0004006528
streamUid D65F916B-60F5-11DE-85DE-AA0004006528

These messages occur between 00:45 and 2:15 (and every day they're move about 2-10 minutes forward in time).

I can't find any batch job that runs around this time and no jobs that include a file which is owned or runned by ARESCHOUG_B user (it's an old user which isn't in use anymore).
Also there are no running processes that is owned by that user.

What can create these messages?
Is it something from the host UGGLA that is trying to connect to the host NODE1?

Running Alpha OpenVMS 7.3-2

Best regards
Fredrik Eriksson

[Steven Schweda]

"Access Control Violation" and "Access
violation" are different. ("HELP /MESS
ACCVIO".)

> Is it something from the host UGGLA that is
> trying to connect to the host NODE1?

It looks that way to me.

> [...] (it's an old user which isn't in use
> anymore).

Apparently it's still in use somewhere.

[Duncan Morris]

Fredrik,

Destination=number = 17 implies the use of FAL.

!% NCL Script SYS$COMMON:[SYSMGR]NET$APPLICATION_STARTUP.NCL;
!% 9-APR-2006 03:26:08.41
!%
!* Session Control Application FAL added 9-APR-2006 03:26:08.41 by SYSTEM
CREATE NODE 0 SESSION CONTROL APPLICATION FAL
SET NODE 0 SESSION CONTROL APPLICATION FAL ADDRESSES = {NUMBER=17} -
,CLIENT = -
,INCOMING ALIAS = TRUE -
,INCOMING PROXY = TRUE -
,OUTGOING ALIAS = TRUE -
,OUTGOING PROXY = TRUE -
,NODE SYNONYM = TRUE -
,IMAGE NAME = SYS$SYSTEM:FAL.EXE -
,INCOMING OSI TSEL =


Duncan

[Volker Halle · Accepted solution]

Fredrik,

please also see:

http://forums11.itrc.hp.com/service/forums/questionanswer.do?threadId=1287033

Volker.

[Jeremy Begg]

Frederik,

I'm guessing there's a self-submitting batch job running on node UGGLA under username ARESCHOUG_B. Do you have access to UGGLA? If so have a look at its batch queues and perhaps also the accounting log, concentrating on the time between midnight and 2:15am.

You could add a DECnet proxy record to your system to map UGGLA::ARESCHOUG_B to a local user with no privileges, then turn on FAL debugging to see what requests are being made. See http://ftp.vsm.com.au/kits/fal.zip
(But of course doing so opens your system to possible undesireable remote access!)

Regards,
Jeremy Begg

[Fredrik.eriksson]

Duncan,
Seems you're correct sir.
Just that file you mentioned contains these lines.

!* Session Control Application FAL added 24-OCT-1997 15:58:47.62 by MALM
CREATE NODE 0 SESSION CONTROL APPLICATION FAL
SET NODE 0 SESSION CONTROL APPLICATION FAL ADDRESSES = {NUMBER=17} -
,CLIENT = -
,INCOMING ALIAS = TRUE -
,INCOMING PROXY = TRUE -
,OUTGOING ALIAS = FALSE -
,OUTGOING PROXY = TRUE -
,NODE SYNONYM = TRUE -
,IMAGE NAME = SYS$SYSTEM:FAL.EXE -
,USER NAME = "FAL$SERVER" -
,INCOMING OSI TSEL =

The new question now is how much will break if I remove this?
Is there some flashy way of doing this via NCL or does it just read it directly from that file?

And thank you for the replies so far :)

Best regards
Fredrik Eriksson

[Duncan Morris]

Fredrik,

slow down!

I was only trying to show you what type of connection was being requested - and not suggesting that you disable FAL.

FAL is the standard Decnet "File Access Listener" - which you almost certainly do not want to disable.

The application startup NCL file is generated by NET$CONFIGURE option "Configure Application database". Although you can edit the file manually, NET$CONFIGURE is the more correct way to manipulate the entries.

Duncan

[Duncan Morris]

The Access Control Violation message shows that a request came from UGGLA (10.7) to NODE1 (10.101).

The contents would suggest that ARESCHOUG_B on UGGLA requested access to file(s) on NODE1 without specifying an access string.

if the job did

DIR NODE1::SYS$LOGIN:

then the destination user reports empty (as in your message).

if the remote job did

DIR NODE1"SOMEBODY BADPWD"::SYS$LOGIN:

then the desintation user would report as "SOMEBODY".

Therefore, you need to look on UGGLA for the source of the operation. You may need to use accounting/auditing logs to track this down.

Duncan

[Fredrik.eriksson]

Thank you for the input :)

I'm gonna look into this abit more, a quick study of my audit/accounting logs revelead this.

----------------------------
Username: ARESCHOUG_B UIC: [ARESCHOUG_B]
Account: Finish time: 29-JUN-2009 02:13:29.90
Process ID: 00006686 Start time: 29-JUN-2009 02:13:25.43
Owner ID: Elapsed time: 0 00:00:04.46
Terminal name: Processor time: 0 00:00:01.09
Remote node addr: Priority: 4
Remote node name: Privilege <31-00>: FFFFFFFF
Remote ID: Privilege <63-32>: FFFFFFFF
Remote full name:
Queue entry: Final status code: 10931238
Queue name:
Job name:
Final status text: %DELETE-W-SEARCHFAIL, error searching for !AS

Page faults: 1296 Direct IO: 66
Page fault reads: 150 Buffered IO: 180
Peak working set: 11952 Volumes mounted: 0
Peak page file: 182368 Images executed: 7

Best regards
Fredrik Eriksson