topic Re: Error accessing authorization file in Operating System - OpenVMS

Error accessing authorization file

Wim Van den Wyngaert — Mon, 03 Dec 2007 08:19:30 GMT

Since a few years we do a set file/prot on the sysuaf file. This every Sunday evening.

Now for the first time I got a batch job that failed to login. It got loginout.exe getting "LOGIN-F-FILEACC, error accessing system authorization file.

How can I change the file protection without getting this conflict. Is there a way for temporarily stopping all processes from doing logins (stop=hold for 0.001 sec).

Wim

Re: Error accessing authorization file

Karl Rohwedder — Mon, 03 Dec 2007 08:30:57 GMT

Why did you set the protection, did someone change it?
If you want 'just to be sure', you may check it beforehand using F$FILE(fil,"PRO").

And perhaps enable auditing on it to check, who changes the protection.

regards kalle

Re: Error accessing authorization file

Wim Van den Wyngaert — Mon, 03 Dec 2007 08:37:58 GMT

Yes this would solve the problem but I wanted to know in general "how can I change the protection on the sysuaf on a running system without having the risk that a process failes".

WIm

Re: Error accessing authorization file

Jan van den Ende — Mon, 03 Dec 2007 19:43:44 GMT

Wim,

I would like to play with your odds in the lottery!

Yes, SET FILE _does_ lock the target.
But, normally, for SUCH a short period that it is a challenge for statistics to hit it.

But you proved that it IS possible.

I would have argued that several other activities do also create short-lived locks on all kinds of objects, and that the designs of VMS is such, that in any fore-seen cases some way around it (eg, short wait) would be in place.
Obviously NOT all cases.

fwiw

Proost.

Have one on me.

jpe

Re: Error accessing authorization file

Hoff — Mon, 03 Dec 2007 21:40:09 GMT

I'd consider enabling security audits on the critical files for modifications (eg: for control access, or control access attempts, etc), and then scan for any events in the auditing log. This as part of a scan for any interesting events in the audit data that might indicate signs of impending or actual trouble.

Re: Error accessing authorization file

John Gillings — Mon, 03 Dec 2007 22:03:35 GMT

Wim,

There is a way to stop logins but it won't help your immediate issue (see later...)

Your simplest solution is a retry loop. If you get a FILEACC error, just retry some "reasonable" number of times, say 20, with or even without a WAIT delay of a second or so. Unless you have an exceptionally busy system, that will work eventually. Report an error if it fails every attempt. It's a batch job so you really don't care how long it takes.

The easiest way to stop other processes from accessing SYSUAF is to open it for exclusive access. From DCL you'd have to do it in a retry loop because other processes may have it open with incompatible sharing options. But that won't help you because you'll be blocking the SET PROT yourself.

You could write a program which obtains exclusive access to the file and sets protection. I think if you use the ACP-QIO interface you may be able to do it without having to retry (low level file system - see chapter 1 of I/O Users Reference Manual), but this seems like extreme overkill to me for what you're trying to achieve.

As Karl suggested, checking the file attributes first to see if it's even necessary to attempt to change the protection will probably solve the problem. Since any process that wants to change it will have the same problem as you have.

I don't believe there's any way for you to change the protection without exposing some risk to other processes logging in. You can probably assume that an interactive or network user will simply retry if their login fails. To protect batch jobs, you could drop the queue limits to 0 before attempting to change the protection, then restore them immediately afterwards (but then you have to weigh up the risk of a failed batch login against the risk that your job will fail to restore the job limits on the queue!). I don't think there's much you can do about network jobs.

Re: Error accessing authorization file

Jess Goodman — Mon, 03 Dec 2007 22:32:26 GMT

I think there is a way to handle this but it's a rather complicated solution, so I would bet you would rather just work-around your problem some other way.

But FYI, you could use loginout callouts so that each step used to authorize the batch job (or logins for other process modes) is under your control.

So then if a LGI$ callback routine returns an error due to SYSUAF being locked your code could wait a bit and then retry the callback routine.

See the LOGINOUT routine chapter of the OpenVMS Utility Routines Manual.

Re: Error accessing authorization file

DECxchange — Tue, 04 Dec 2007 03:10:45 GMT

I don't know if there is any reason to change the file protection on the system authorization file. I'm assuming you are referring to SYSUAF.DAT, right? You might want to also look at

$ dir/prot/owner sys$sytem syauaf.dat

I think the owner should be user SYSTEM.

I would try some other method of security on the sysuaf other than setting its protection.

Re: Error accessing authorization file

EdgarZamora_1 — Tue, 04 Dec 2007 13:54:49 GMT

I don't know how many batch queues you have, but one "workaround" would be to stop/next your batch queue(s) temporarily while you do the set protection on the uaf file (also wondering why you are doing this on a daily basis) then restarting the queues after the set protection.

Re: Error accessing authorization file

Wim Van den Wyngaert — Tue, 04 Dec 2007 14:09:10 GMT

Yes but there are other processes too (network, interactive).

I think I will leave the situation as it is as on the hour of execution there is nothing important running.

Wim

Re: Error accessing authorization file

Willem Grooters — Fri, 07 Dec 2007 09:30:05 GMT

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.

Re: Error accessing authorization file

Wim Van den Wyngaert — Fri, 07 Dec 2007 09:53:53 GMT

Willem,

That is a problem for SOX. No go.

Wim

Re: Error accessing authorization file

An Vercammen — Mon, 10 Dec 2007 12:48:25 GMT

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?

Re: Error accessing authorization file

Volker Halle — Mon, 10 Dec 2007 12:56:10 GMT

An,

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

Volker.

Re: Error accessing authorization file

An Vercammen — Mon, 10 Dec 2007 13:01:18 GMT

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...

Re: Error accessing authorization file

Wim Van den Wyngaert — Mon, 10 Dec 2007 13:01:39 GMT

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

Wim

Re: Error accessing authorization file

Wim Van den Wyngaert — Mon, 07 Jan 2008 07:08:39 GMT

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

Re: Error accessing authorization file

John Gillings — Tue, 08 Jan 2008 01:27:30 GMT

>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...

Re: Error accessing authorization file

Wim Van den Wyngaert — Tue, 08 Jan 2008 07:14:48 GMT

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

Re: Error accessing authorization file

John Gillings — Thu, 10 Jan 2008 00:29:28 GMT

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.