Error accessing authorization file

[Wim Van den Wyngaert]

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

[Karl Rohwedder]

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

[Wim Van den Wyngaert]

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

[Jan van den Ende]

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

[Hoff]

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.

[John Gillings]

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.

[Jess Goodman]

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.

[DECxchange]

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.

[EdgarZamora_1]

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.

[Wim Van den Wyngaert]

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

[Willem Grooters]

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.

[Wim Van den Wyngaert]

Willem,

That is a problem for SOX. No go.

Wim

[An Vercammen]

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]

An,

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

Volker.

[An Vercammen]

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]

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

Wim

[Wim Van den Wyngaert]

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

[John Gillings]

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

[Wim Van den Wyngaert]

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

[John Gillings]

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.

[Wim Van den Wyngaert]

Correct John. My first guess was that it was the set file on the files themselves. But after checking what the script did I found it also changed directories.

Wim

[Jon Pinkley]

Wim,

What version of VMS are you using?

To me this seems like a bug in the implementation of the f$search lexical function, especially if it isn't returning an error status. Can you supply a reproducer?

Jon

[Wim Van den Wyngaert]

Job,

These are the 2 jobs you have to submit. The 2nd one will loop until the first one is submitted. The .dir file is my home directory.

IMO lexicals handle open files badly. I'm on 7.3.

$b:
$ on warning then exit
$ set file ops$mgr:[000000]wvw.dir /prot=(w:rwed)/own=sysmgr_wvw
$ goto b


$b:
$ if f$sea("OPS$MGR:[WVW]wim.lis") .eqs. "" then exit
$ x=f$sea("login.com") !reset
$ goto b

Wim

[Hein van den Heuvel]

Just a few observations.

1) The behaviour is the same under OpenVMS 8.3

2) The error is trapped by RMS. DCL chooses to ignore it.

The full errors are:
STS: %RMS-E-FLK, file currently locked by another user
STV: %SYSTEM-W-ACCONFLICT, file access conflict

3) Strictly speaking this is correct.
- The directory file is open for write.

4) You can 'see' the error happen with SET WATCH FILE/CLASS=ALL

good:

%XQP, Thread #0, Volume protection: Access requested: 00000001, Status: 00000001, PrvUsd: 00000000
%XQP, Thread #0, File protection (101369,44,0): Access requested: 00000004, Status: 00000001, PrvUsd: 00000000
%XQP, Thread #0, Read only directory access (101369,44,0)
%XQP, Thread #0, Directory scan for: TMP.TMP;0, Status: 00000001
%XQP, Thread #0, Lookup (114092,113,0) Status: 00000001

bad:

%XQP, Thread #0, Volume protection: Access requested: 00000001, Status: 00000001, PrvUsd: 00000000
%XQP, Thread #0, File protection (101369,44,0): Access requested: 00000004, Status: 00000001, PrvUsd: 00000000
%XQP, Thread #0, Lookup (0,0,0) Status: 00000800

Reproducer in C below.

Cheers,
Hein.

$! --- l1.com ---
$i = 0
$on warning then exit
$loop:
$i = i + 1
$set file tmp.dir/prot=w:rwe/own=hein
$if i .eq. 1000*(i/1000) then write sys$output i
$goto loop

$! ---- l2.com ----
$i = 0
$on warning then exit
$loop:
$i = i + 1
$if f$search("[.tmp]tmp.tmp;0").eqs."" then goto done
$x = f$search("sys$login:login.com")
$if i .eq. 1000*(i/1000) then write sys$output i
$goto loop
$done:
$write sys$output i
$exit


/* l2.c. Hein van den Heuvel
** usage: $mcr dev:[dir]l2 [.sub]file.ext
*/
#include string
#include stdio
#include fab
#include nam

main(int argc, char *argv[]) {

int stat = 1, i = 0, sys$parse(), sys$search();
struct FAB fab = cc$rms_fab;
struct NAM nam = cc$rms_nam;
char esa[256], rsa[256], *func;

fab.fab$l_fna = argv[1];
fab.fab$b_fns = strlen(argv[1]);
fab.fab$l_nam = &nam;

nam.nam$l_esa = (char *) esa;
nam.nam$b_ess = 255;
nam.nam$l_rsa = (char *) rsa;
nam.nam$b_rss = 255;

while (1 & stat) {
if (!(++i % 1000)) printf ("%d\n",i);
func = "parse";
stat = sys$parse ( &fab ) ;
if ( 1 & stat ) {
func = "search";
stat = sys$search ( &fab );
}
}
printf ("i=%d, %s, sts=%d, stv=%d\n", i, func, fab.fab$l_sts, fab.fab$l_stv);
return stat;
}