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

ACL_SCRUB for Alpha

SOLVED
Go to solution
Zeni B. Schleter
Regular Advisor

ACL_SCRUB for Alpha

We have used the ACL_SCRUB from the freeware distribution for many years on Vaxen. I tried looking for an implementation of it for Alphas. It has been a useful cleanup tool for removing ACEs that do not have proper identifiers on the system and generating a output file that can be searched for files with UICs that no longer belong to valid users. Perhaps there is a better way of cleaning up ownerships and ACLs in this century ?

TIA
27 REPLIES
Wim Van den Wyngaert
Honored Contributor

Re: ACL_SCRUB for Alpha

I don't know acl_scrub but you can check if dfu of the freeware cd does the same.
DFU SEARCH dev /ACE=identifier
will search for files having an acl that mention "identifier".

Wim
Wim
Robert Gezelter
Honored Contributor

Re: ACL_SCRUB for Alpha

Zeni,

If you have sources, you should be able to recompile it for Alpha (and Itanium). If you do not have the sources, you may try be able to use the binary translator to run it on the later architectures.

- Bob Gezelter, http://www.rlgsc.com
Zeni B. Schleter
Regular Advisor

Re: ACL_SCRUB for Alpha

The DFU requires that you know what you are looking for. I could (and may) just set up a procedure to output Dir/SEC and the look for %8 or the like to indicate ACEs with missing identifiers. I would still have to setup something to remove them - carefully.

I tried rebuilding the C files. The Get_header had a lot of mismatch types and pointers. Sorry to say I have avoided the C language with a true FORTRAN bias. Sounds like this will be a useful exercise for me.
Robert Gezelter
Honored Contributor

Re: ACL_SCRUB for Alpha

Zeni,

Before setting out to work with an unfamiliar source base, try running the binary image through the translator.

As I noted in my recent OpenVMS Technical Journal paper entitled "Strategies for Migrating from Alpha and VAX systems to HP Integrity Serves on OpenVMS", (see http://www.rlgsc.com/publications/vmstechjournal/migrationstrategies.html ), the translator is an excellent strategic tool for infrequently used utilities.

It is worth noting that from the advent of Alpha (circa 1992) through OpenVMS 7.3-2 in December 2003 (see the history of OpenVMS releases at http://h71000.www7.hp.com/openvms/openvms_supportchart.html ), MONITOR on Alpha was a binary translation of the VAX image.

As noted in my paper, I have used the binary translator both on VAX and Alpha binaries, with reasonable results.

- Bob Gezelter, http://www.rlgsc.com
Zeni B. Schleter
Regular Advisor

Re: ACL_SCRUB for Alpha

It appears that VEST is not available to us. In looking through the "Migratin of an Application..." manual , I noticed the CC/STANDARD=VAX that does allow the alpha to produce an object file for those with the problems. There is still a macro that is not compiling. It is complaining that
% AMAC-E-GENERROR, generated ERROR: 0 $TRAN requires symbols defined in ARCH_DEFS.MAR

Sys$library: contains ARCH_DEFS.MAR and ARCH_DEFS.H . Helpful but I am equally weak in macro. I have plenty of manuals to look through to see how to get the compiler to incorporate the definitions.

Thanks for looking.
Hoff
Honored Contributor

Re: ACL_SCRUB for Alpha

ACL_SCRUB is apparently based on some code from Joe Meadows and Andrew Potter.

This looks to be the source code...

http://mvb.saic.com/freeware/vax89b2/potter/

And for completeness, there's a DCL tool in the Freeware 000TOOLS directory that can be used to reset the BACKUP saveset attributes after you haul that file over via FTP, after FTP stomps on the saveset file attributes.

Unpack the saveset, and have a look at the code.

As for cleaning up, my preference is to not delete identifiers and not to delete usernames. Disuser the usernames, yes.
Robert Gezelter
Honored Contributor

Re: ACL_SCRUB for Alpha

Zeni,

VEST is available as a download kit from the HP OpenVMS www site. It has not, to the best of my recollection, been part of the standard distribution for some time.

I would, however, also agree with Hoff's comment about deletions, to wit: delete identifiers with care.

- Bob Gezelter, http://www.rlgsc.com
Jan van den Ende
Honored Contributor

Re: ACL_SCRUB for Alpha

Bob wrote:
>>>
I would, however, also agree with Hoff's comment about deletions, to wit: delete identifiers with care.
<<<

Oh yeah!
And all the more so, if you allow identifiers to be created with the default value!!
Next time you add an identifier, chances are that the value is used again, and... it _IS_ the value that is important, the name is just for human convenience.

WE have a liitle algorithm to derive an identifier value from the first 4 letters of the identifier name, (with the last 2 hex digits free, enabling choice to to differentiate the rest of the name)
At least we have a fairly decent way of knowing what an identifier is ( or WAS !!!) for.

Bottom line: Better NOT delete identifiers.

hth

Proost.

Have one on me.

jpe
Don't rust yours pelled jacker to fine doll missed aches.
Hoff
Honored Contributor

Re: ACL_SCRUB for Alpha


>>>% AMAC-E-GENERROR, generated ERROR: 0 $TRAN requires symbols defined in ARCH_DEFS.MAR<<<

>>>Sys$library: contains ARCH_DEFS.MAR and ARCH_DEFS.H<<<

You're dealing with Macro32, not C code.

FWIW, the CC/STANDARD=VAXC stuff sets C to be far more tolerant of the ancient C coding constructs, and the various ancient C coding errors and typical latent bugs that could be permitted by the VAX C compiler. It's a bug compatibility mode for the source input.

As for fixing the error in the Macro32 code...

$ MACRO -
/OBJECT=SYS$LOGIN:name.OBJ - SYS$SHARE:ARCH_DEFS.MAR+SYS$LOGIN:name.MAR

In the above, "name" is the name of the state table source file, and the object file.

There are versions of ARCH_DEFS around.

There should be an example of this basic DCL command sequence and a full Macro32 source code example of using the lib$tparse and lib$table_parse stuff over in the GNM Freeware package.

http://h71000.www7.hp.com/freeware/freeware80/gnm/

Zeni B. Schleter
Regular Advisor

Re: ACL_SCRUB for Alpha

I had found the vax89b2 early on. I fixed the structure but only two of the files were successfully removed from the backup set. The dates were 1989 and the text file matched exactly what I had. Since the title included "VAX" was was not hopeful that there would be Alpha results.

I found a similar Macro statement for compiling the arch_defs.mar with the macro code. Now I am getting "DATINCODE" messages. .long gives a problem.

I searched the ITRC web site for VEST but did not find any hits.

Maybe it will all fall in place tomorrow. I have the MACRO-32 Porting and User's Guide.
Robert Gezelter
Honored Contributor
Solution

Re: ACL_SCRUB for Alpha

Zeni,

My apologies.

VEST is an acronym. The "product" name is/was DECMigrate. Information can be found at http://h71000.www7.hp.com/openvms/products/omsva/omsva.html

- Bob Gezelter, http://www.rlgsc.com
Robert Gezelter
Honored Contributor

Re: ACL_SCRUB for Alpha

Zeni,

For completeness, the acronym VEST stands for VAX Environment Software Translator".

The latest name is "OpenVMS Migration Software for VAX to Alpha" (with the acronym "OMSVA").

- Bob Gezelter, http://www.rlgsc.com
Jon Pinkley
Honored Contributor

Re: ACL_SCRUB for Alpha

While I agree that deleting user accounts and the associated Identifiers has more downsides than upsides, VMS does not normally reuse the same value for a general identifier.

That is, if you issue a commands like

$ mcr authorize show /id testid /ful
%UAF-E-SHOWERR, unable to complete SHOW command
-SYSTEM-F-NOSUCHID, unknown rights identifier
$ mcr authorize add /id testid
%UAF-I-RDBADDMSG, identifier TESTID value %X800100CB added to rights database
$ mcr authorize rem /id testid
%UAF-I-RDBREMMSG, identifier TESTID value %X800100CB removed from rights database
$ mcr authorize add /id testid
%UAF-I-RDBADDMSG, identifier TESTID value %X800100CC added to rights database
$

The "next" value to be assigned to an identifier is kept in the RIGHTSLIST record with key value $$MAINTENANCE_RECORD. AUTHORIZE will attempt to use the value in the last 8 bytes of the $$MAINTENANCE_RECORD, and if that is already in use, it will keep incrementing until if gets to an unused value, and will then update the record with the next highest value.

I am not aware of any way to reset the value other than rewriting the $$MAINTENANCE_RECORD, i.e. it won't happen by accident.

Stock VMS does not remember what UICs have been used, at if it does, I am not aware of where it does. We have a command procedure we use to create new accounts, and each group has a template account, and we store the HEX value of the next UIC in the /owner field, just so we don't reuse UICs.

++++++++++++++++++++++++++++++++++++++++++++

Blue Sky mode on:

I wish each disk had a reserved file like [000000]RIGHTSLIST.SYS that contained the set of identifiers that were used on the disk, and this could be optional like QUOTA.SYS is for people that didn't want it.

Then when a volume was mounted, a consistency check could be done against the current RIGHTSLIST on the system, and if there were conflicts, it could refuse to mount the disk unless something like /override=rightslist_processing was specified. An anal/disk/repair would rebuild the file from the UICs and Identifiers found on the disk and the current RIGHTSLIST.DAT file.

The reason for such a check is to avoid accidentally granting ownership or access to files on the volume.
it depends
Zeni B. Schleter
Regular Advisor

Re: ACL_SCRUB for Alpha

I had looked but did not see...
Bob, Thanks for putting me directly on the page with the info and the link for the download. I had found information about Vest/Decmigrate/OMSVA but not specific about licensing or the download link.

Re: about deleting. Sort of too-late for not doing it. I keep info on removed Identifiers and accounts.
Wim Van den Wyngaert
Honored Contributor

Re: ACL_SCRUB for Alpha

I tried to compile it :

.PSECT DATA,RD,WRT,NOEXE in the beginning of .mar file
.PSECT CODE,RD,NOWRT,EXE before entry in .mar file

/stand=vaxc
all char * of cld.h replaced by static char *
and put delete_ace in comment to be safe

replace for by fortran

removed /option from link and added /nonative.

It runs. Displays confusing output like

file Owner_uic = [0,6] = []
for some time, displays some ace's
and aborts on first "if" in display.c.

Did something change between vax and alpha on the subject of indexf.sys ?

Wim
Wim
Zeni B. Schleter
Regular Advisor

Re: ACL_SCRUB for Alpha

I will try the OMSVA (migration tool) on a test machine and see what kind of results happen. It may completely rule out the use for ACL_SCRUB software for Alpha hardware.

Thanks to all for the useful discussion.

P.s. Wim, I meant to add 8 points for your follow-up message about the .PSECT but after submitting the points , I saw the result was 1 . Not intentional. Don't know how to fix.
Jan van den Ende
Honored Contributor

Re: ACL_SCRUB for Alpha

eni,

>>>
I meant to add 8 points for your follow-up message about the .PSECT but after submitting the points , I saw the result was 1 . Not intentional. Don't know how to fix.
<<<

Sorry _NO_ way to change submitted points (AFAIK, not even be asking the moderators).
In practice, that means you can NEVER revoke points once given.
In a case like this however, just ask the intended receiver to reply once more, just to give the extra points to the extra answer.

hth

Proost.

Have one on me.

jpe
Don't rust yours pelled jacker to fine doll missed aches.
Wim Van den Wyngaert
Honored Contributor

Re: ACL_SCRUB for Alpha

Sorry to not have solved the problem. I was a programmer once but not a VMS one (cobol VMS/HP3000/Unix). I think the problem is a pointer issue that was forgiven / autocorrected by the VAX compiler.

BTW : could you post the normal output of the program ? I might find it next week.

Wim
Wim
Zeni B. Schleter
Regular Advisor

Re: ACL_SCRUB for Alpha

The OMSVA software will work. I have not completely tested it but the resulting image does run and does create the expected output file.

The output can be lengthy if there are a lot of ACEs. Each file and its associated ACEs are noted like:
_DSA0:[SYS2]DNS$SERVER.DIR;1
Identifier ace: (IDENTIFIER=NETWORK,OPTIONS=DEFAULT,ACCESS=NONE)
Identifier ace: (IDENTIFIER=NETWORK,ACCESS=NONE)

Typically, I search the output file for "owner_uic" to find files that are not owned by valid UICs

An example (forgive the Wrap) is >
DSA0:[VMS$COMMON.SYSLIB]LNGSPLSHR.EXE;6 Owner_UIC = [15,1] = []

ACEs for sub-systems are noted but not modified. Audit ACEs are noted as "unknown". ACEs that are for unowned UICs or invalid Identifiers are removed.
Hoff
Honored Contributor

Re: ACL_SCRUB for Alpha

Based on what I'm finding in the acl_scrub source code, there are definitely some nasty bugs here, and bugs that the newer compiler is finding. I'd not choose to run this particular code -- whether ported or translated -- without a whole lot of testing, based on what I see this source code doing.

The current code is also ODS-2 only, and that may or may not matter for this case. It's looking at file headers all over the place.

If somebody has a target practice configuration and particularly one that they don't mind stomping on, please contact me offline.
Dean McGorrill
Valued Contributor

Re: ACL_SCRUB for Alpha

For removing aces, I've usually taken a file
with none. eg create an empty file say
dummy.dat with no ace/acl's then do a..

$ set file/acl/like=dummy.dat *.*

or disk:[*...]*.*;* if you want them all
gone

Dean
Robert Gezelter
Honored Contributor

Re: ACL_SCRUB for Alpha

Zeni,

Reading today's posts, I should perhaps clarify some things about binary translators in general, more for the sake of leaving a record for others who read this thread in the future.

I have not had the chance to review the sources for ACL_SCRUB as Hoff has apparently had the chance to do (instead spent the day traveling between meetings stuck in traffic caused by some severe thunderstorms in the NYC area, but I digress).

Binary translators do very well at translating correct code. This is particularly useful in situations where the sources are correct, but
- are written using otherwise obsolescent language versions (e.g., VAX C)
- where sources are incomplete
- large numbers of clerical edits must be made to reflect the changed architecture.

I firmly advocate the use of translators as strategic tools, but they are not a panacea. If the code has bugs, binary translators are bug-for-bug compatible. Additionally, since translators are almost invariably used in concert with new OS versions, there is always the potential for marginally legal uses of the APIs to not function as intended.

As always, caution is advised.

If I have been unclear, please feel free to follow up this posting. Also, please feel free to contact me directly offline.

- Bob Gezelter, http://www.rlgsc.com
Zeni B. Schleter
Regular Advisor

Re: ACL_SCRUB for Alpha

For the Cautionary notes of Hoff and Bob Gezelter, duly noted.

As a review, I am trying to remove obsolete ACEs across a wide number of disks (possibly). The reason for the obsolete ACEs are because of accounts that were removed or identifiers that were removed. In this thread, the removal of unused accounts and identifiers was brought into question but that was not the point of the thread.

The latest rendition of OMSVA was delivered with OpenVMS v7.3-1. I successfully used that product to run ACL_SCRUB on a OpenVMS v7.3-2 Alpha. I had to use the /INTERPRET switch. So this does work but with the cautionary notes, I don't know that I should. I will spend some time going over what Wim suggested to get a clean compile and what the code really does.

Thanks to All.
Hoff
Honored Contributor

Re: ACL_SCRUB for Alpha

I've a ported and compiling and linking version of ACL_SCRUB, FWIW; updated to V8.3. It is not debugged (nor am I going to spend much time on same right now due to other work in the queue), though I've updated the code to recognize all current ACE types, and to lock out the ACE delete path unless a (newly-added) /DELETE qualifier is specified to allow said ACE deletion.

Here's the current source port...

http://64.223.189.234/node/426