Operating System - OpenVMS
cancel
Showing results for 
Search instead for 
Did you mean: 

Error accessing authorization file

 
Willem Grooters
Honored Contributor

Re: Error accessing authorization file

I agree you should find out why it's needed in the first place. If you need to reset security, it's always too late.

Preventing interactive users to login, set logins to zero. To prevent batch procedures to login, set queues on hold (STOP/NEXT). To prevent network users to login, disable services that can be accessed (thou that may cause severe problems outside).

To prevent login errors, you might think of this method (I _know_ it's not perfect at all and may have caveats, but it'sa way to get around it):

$ BACKUP/IGNORE=INTERLOCK SYSUAF.DAT SYSUAF1.DAT
$ BACKUP/IGNORE=INTERLOCK RIGHTSLIST.DAT RIGHTSLIST11.DAT
$ SET FILE/PROT=(W:RWED) SYSUAF1.DAT
$ OldUAF = F$TRNLNM("SYSUAF","LNM$SYSTEM")
$ OldRL = F$TRNLNM("RIGHTSLIST","LNM$SYSTEM")
$ DEFINE/SYSTEM/EXEC SYSUAF SYSUAF1.DAT

do your job on SYSUAF.DAT and RIGHTSLIST.DAT

$ IF OldUAF .NES. ""
$ THEN
$ DEFINE/SYSTEM/EXEC SYSUAF 'OldUAF'
$ ELSE
$ DEASSIGN/SYSTEM/EXEC SYSUAF
$ ENDIF
$ IF OldRL .NES. ""
$ THEN
$ DEFINE/SYSTEM/EXEC RIGHTSLIST 'OldRL'
$ ELSE
$ DEASSIGN/SYSTEM/EXEC RIGHTSLIST
$ ENDIF
$ DELETE SYSUAF1.DAT;*
$ DELETE RIGHTSLIST1.DAT;*

You will certianly loose information about logins during the transition period, and usage of AUTHORIZE should be prevented (or disabled); you'll have to decide whether that is a problem or not.
Willem Grooters
OpenVMS Developer & System Manager
Wim Van den Wyngaert
Honored Contributor

Re: Error accessing authorization file

Willem,

That is a problem for SOX. No go.

Wim

Wim
An Vercammen
Occasional Visitor

Re: Error accessing authorization file

Strange, today, I have this error for the first time as well! At least 3 batch jobs failed to start this morning, with "LOGIN-F-FILEACC, error accessing system authorization file." , seen in accounting.
As far as I know, we do not change the security on the sysuaf.dat.
The only job that opens the file is QUEUE_MANAGER at the moment.

Other batch jobs ran OK.

What else can cause this confict?
Volker Halle
Honored Contributor

Re: Error accessing authorization file

An,

check OPERATOR.LOG or the OpenVMS console (OPA0:) for any unusual errors seen at the time of this failure.

Volker.
An Vercammen
Occasional Visitor

Re: Error accessing authorization file

No errors at all in the Operator.log.

Some batch jobs still fail to start at the moment, some start OK.
Some failed jobs can be started afterwards, and vice versa, but they all use the same account.

Can I find out who locks the SYSUAF, if it is a lock at all...
Wim Van den Wyngaert
Honored Contributor

Re: Error accessing authorization file

And check in accounting if you can the one who did it.

Wim
Wim
Wim Van den Wyngaert
Honored Contributor

Re: Error accessing authorization file

Analogue problem today. During the set file/prot a f$sea was done on one of the files. As a result the f$sea returned "".

I will remove the set file/prot.

Wim
Wim
John Gillings
Honored Contributor

Re: Error accessing authorization file


>Analogue problem today. During the set
>file/prot a f$sea was done on one of the
>files. As a result the f$sea returned "".

Huh? This must be something else entirely.

F$SEARCH does NOT require any kind of access to the target file. It can't be blocked by FLK, FILEACC or PRV. The only access that's required is R (or even E) to the containing directory tree. The file itself can be ACCESS=NONE, you can still search for it and determine its name.

Try it yourself...
A crucible of informative mistakes
Wim Van den Wyngaert
Honored Contributor

Re: Error accessing authorization file

I tried 2 batch jobs : 1 doing set file/prot/own of the directroy and 1 job doing f$sea of the file (and a reset of the f$sea). Both in a loop.

As soon as I started the set file/prot job, the f$sea job aborted (f$sea returning "").

Wim
Wim
John Gillings
Honored Contributor

Re: Error accessing authorization file

Wim,

>1 doing set file/prot/own of the
>directroy and 1 job doing f$sea of
>the file

Just to make sure we're 100% clear here...

Can you confirm that SET FILE/PROT and F$SEARCH of THE SAME FILE do NOT clash?

It's only a SET FILE/PROT of the DIRECTORY CONTAINING the target file of the F$SEARCH which causes trouble?

If so, that confirms what I said in my previous post, but it's NOT the same as your claim: "During the set file/prot a f$sea was done on one of the files. As a result the f$sea returned ""."

As I said F$SEARCH does not require any access to the target file, but it does require access to the enclosing directories.
A crucible of informative mistakes