A tool to delete all Pathworks ACEs ?

[Jeremy Begg]

Hi,

Running CIFS V1.1-ECO1 PS006 on OpenVMS IA64 V8.3-1H1.

We've discovered that CIFS is tripping up on Pathworks ACEs: if the file has a Pathworks ACE, the Windows client can't delete or rename the file.

I've identified 13,000 files with Pathworks ACEs and now I'm wondering how to remove those ACEs. The DCL command

$ SET SECURITY/ACL=(ace)/DELETE

doesn't work because the Pathworks ACEs are too long for DCL's command buffer.

Does anyone know of a tool which can delete these ACEs?

Thanks,
Jeremy Begg

[Steven Schweda]

No bets, but Zip+UnZip might strip off the
ACEs without doing too much damage. UnZip
(6.0) has a "-X" option to tell it to restore
ACLs. The default is not to do it. You may
lose the ownership UIC, too, however. As the
"-h" help says:

-X restore owner/ACL protection info

Testing could be educational.

[Steven Schweda]

BACKUP /INTERCHANGE?

HELP BACKUP /INTERCHANGE says:

o Access control lists are not copied.

[Thomas Ritter]

$ SET SECURITY/ACL=(ace)/DELETE

doesn't work because the Pathworks ACEs are too long for DCL's command buffer.

Longer than 4096 bytes ? Are you using extended DCL ?

[Jeremy Begg]

Hi Steven,

Thanks for the suggestions but neither is suitable -- I need to delete the Pathworks ACEs but not any of the other ACEs on the files, and preferably without changing the file ownership or UIC-based protection, either.

Regards,
Jeremy Begg

[Jon Pinkley]

Jeremy,

When you say the DCL buffer is too small, is that true if you split the command across several continuation lines (i.e. with "-" at the end of the line)?

Can you show use what a pathworks ACL looks like? I.e. the output of

$ directory/security pathworks_file

If it is ok to delete all the whole ACL, instead of just the pathworks related ACEs, then the following should work.

$ set secruity/acl/delete

If there are other ACEs you don't want to delete, than that won't be a good solution.

Or if all the "extra" ACEs are the same, then a combination of a default ACE on the destination directory, and backup/interchange will work (as suggested by Steven Schweda). That strips the ACL from the source file and applies any default ACEs from the destination directory, and had the "advantage" of not modifying the creation or modification dates on the files, where set security will update the modification date, and I am not aware of any way to avoid it if set security is used.

The ultimate solution is to write a program, but I think you were trying to avoid that.

Jon

[Jon Pinkley]

Jeremy,

I didn't see your response before I sent mine. So it doesn't seem that my suggestions will work, especially if the files contain ACEs that can't be applied with default ACEs on the target directory.

BTW, backup/interchange can be used with /owner=original, so it doesn't imply that the ownership of the files will have to change.

Jon

[Jeremy Begg]

Here is the file ...

D2:[web_advertising]Marketing^_Calendar^_WEB^_ADVERT.xls;1 object of class FILE
Owner: [305,12]
Protection: (System: RWD, Owner: RWD, Group, World)
Access Control List:
(UNKNOWN=%X86,SIZE=%D208,FLAGS=%X0400,ACCESS=%X06900000,DATA=%X00000001,%X000000BC,%X000000BC,%X80140001,%X00000084,
%X000000A0,%X00000000,%X00000014,%X00700002,%X00000004,%X00180000,%X001F01FF,%X00000201,%X05000000,%X00000020,%X00000220,
%X00180000,%X001301BF,%X00000201,%X05000000,%X00000020,%X00000225,%X00240000,%X001F01FF,%X00000501,%X05000000,%X00000015,
%X81001D39,%X433F040C,%X317C0A05,%X00000427,%X00140000,%X001301BF,%X00000101,%X01000000,%X00000000,%X00000501,%X05000000,
%X00000015,%X81001D39,%X433F040C,%X317C0A05,%X00000427,%X00000501,%X05000000,%X00000015,%X81001D39,%X433F040C,%X317C0A05,
%X00000201)
(UNKNOWN=%X80,SIZE=%D46,FLAGS=%X0C00,ACCESS=%X06900000,DATA=%X00000008,%X00000001,%X0000041E,%X00000120,%X00000000,
%X00000000,%X38C50000,%X38C5892E,%X38C5892E,%X00008930)
(IDENTIFIER=[USER1],ACCESS=READ+WRITE+EXECUTE+DELETE)
(IDENTIFIER=[305,12],ACCESS=READ+WRITE+EXECUTE+DELETE)
(IDENTIFIER=WEB_AD_USER,ACCESS=READ)
(IDENTIFIER=PRICES_DEPT_USER,ACCESS=READ)
(IDENTIFIER=STUDIO_USER,ACCESS=READ)
(IDENTIFIER=ADMIN_USER,ACCESS=READ+WRITE+EXECUTE+DELETE+CONTROL)
(IDENTIFIER=WEB_AD_RW,ACCESS=READ+WRITE+EXECUTE+DELETE+CONTROL)

And here is a little command procedure I prepared to delete the Pathworks ACEs:

$ set security D2:[web_advertising]Marketing^_Calendar^_WEB^_ADVERT.xls;1/acl=(-
(UNKNOWN=%X86,SIZE=%D208,FLAGS=%X0400,ACCESS=%X06900000,DATA=%X00000001,%X000000BC,%X000000BC,%X80140001,%X00000084,-
%X000000A0,%X00000000,%X00000014,%X00700002,%X00000004,%X00180000,%X001F01FF,%X00000201,%X05000000,%X00000020,%X00000220,-
%X00180000,%X001301BF,%X00000201,%X05000000,%X00000020,%X00000225,%X00240000,%X001F01FF,%X00000501,%X05000000,%X00000015,-
%X81001D39,%X433F040C,%X317C0A05,%X00000427,%X00140000,%X001301BF,%X00000101,%X01000000,%X00000000,%X00000501,%X05000000,-
%X00000015,%X81001D39,%X433F040C,%X317C0A05,%X00000427,%X00000501,%X05000000,%X00000015,%X81001D39,%X433F040C,%X317C0A05,-
%X00000201),-
(UNKNOWN=%X80,SIZE=%D46,FLAGS=%X0C00,ACCESS=%X06900000,DATA=%X00000008,%X00000001,%X0000041E,%X00000120,%X00000000,-
%X00000000,%X38C50000,%X38C5892E,%X38C5892E,%X00008930))/delete
$ show security D2:[web_advertising]Marketing^_Calendar^_WEB^_ADVERT.xls;1
$ exit

But DCL can't cope:

@x.com
%DCL-W-TKNOVF, command element is too long - shorten
\(UNKNOWN=%X86,SIZE=%D208,FLAGS=%X0400,ACCESS=%X06900000,DATA=%X00000001,%X000000BC,%X000000BC,%X80140001,%X00000084,%X000000A0,%X0
0000000,%X00000014,%X00700002,%X00000004,%X00180000,%X001F01FF,%X00000201,%X05000000,%X00000020,%X00000220,%X00180000,%X001
$

Regards,
Jeremy Begg

[Jon Pinkley]

Jeremy,

Google found this:

http://h71000.www7.hp.com/doc/82final/6543/6543pro_010.html#deleteace

see if that will do what you want.

Jon

[Thomas Ritter]

Jeremy, your command line is less than 700 characters.

With extended DCL, the length of the command line increases from 255 characters to 4096. Using hyphens the command may be extended up
to 8192 characters.

I dont have a box available now, but by enabling extended DCL your procedure may work. Under 8.2+ this can be done at the process level.
Look at help dcl or something like that.

[Jeremy Begg]

Nice suggestion but unfortunately no good as that program is part of the Advanced Server kit -- and therefore has not been made available on Integrity.

However I have a call open to HP about this one and will request they build it for Integrity.

Thanks,
Jeremy Begg

[David Jones_21]

Attached is the C source for the program I used.

[Jeremy Begg]

Hi David,

Looks promising, but it needs another file "modrevdate.h" to build.

Thanks,
Jeremy Begg

[Thomas Ritter]

Maybe $ SET PROCESS/PARSE_STYLE=extended

[Jon Pinkley]

Thomas,

I may be wrong, but I still think there is 255 character limit on each DCL token.

This is on Alpha OpenVMS V8.3

$ help/mess TKNOVF


TKNOVF, command element is too long - shorten

Facility: CLI, Command Language Interpreter (DCL)

Explanation: An element (that is, any string placed between two delimiters)
in the command line exceeds the maximum length of 255 bytes.

User Action: Correct and reenter the command.


David's program is the way to go, once he provides the modrevdate.h file.

Jon

[Jeremy Begg]

Well, I found the magic incantation to expand DCL's command line buffer.

$ HELP SET PROCESS/TOKEN

tells you all about it. (I couldn't find this in any of the VMS 8.x "New Features" or "Release Notes" documentation.)

Unfortunately it still didn't work ...

%SET-E-NOHIDDEN, cannot modify hidden ACEs

Those Pathworks engineers clearly didn't want you messing with their security! :-)

Regards,
Jeremy Begg

[Jon Pinkley]

Jeremy,

If you don't care if the modification date is changed, you can probably remove #include and references to the functions that must be provided in modrevdate.h; save_revdate, format_revdate and restore_revdate. I removed the #include modrevdate.h and compiled, and these popped out.

Unless you are in a big hurry, I would wait for David to provide modrevdate.h, unless you really want the revision dates to be updated.

My guess is that you have a much higher probability of getting a response from David before you get an IA64 version of PWRK$DELETEACE.EXE. And David's program has the added benefit of being able to tweak the program to your specific needs.

Otherwise, you could parse the output of directory file, and generate the SET SECURITY command to delete the ACL, and recreate the non-pathworks ones.

From help set security/delete

o The expression /ACL=aces/DELETE=ALL deletes the existing ACL (if any) and create a new ACL with the ACEs specifies on the /ACL qualifier.

Note that "solution" will not be any better than David's program with all the revision date preservation code removed, and it would probably be a lot easier to modify David's code than to write DCL to parse and recreate the correct set security commands needed to delete and recreated the ACL after turning on extended DCL tokens.

Just my opinion,

Jon

[Jan van den Ende]

Jeremy,

this is from my rusting bio-memory, and from way back when, but

>>>
Unfortunately it still didn't work ...

%SET-E-NOHIDDEN, cannot modify hidden ACEs
<<<

ISTR that the BYPASS privilege (ooch!) could overcome that.

IF my memory serves me (and you) well...

At least worth a try.

fwiw

Proost.

Have one om me.

jpe

[David Jones_21]

Sorry about that. I wrote it in 2005 when we dropped pathworks and started using Samba.

I light of information on the HP support site, you might want to fixup the is_pathworks_ace() function to more accurately discern the ACEs to eliminate.

[David Jones_21 · Accepted solution]

Dangit, brain fog this morning. This attachment actually has all the files you need.

[Hoff]

If you're just mowing off entire ACLs en-mass, then

SET SECURITY /ACL /DELETE=ALL ddcu:[dir...]*.*.*

seems rather simpler.

And for cleaning up ACLs and expunging stale identifiers in general, the acl_scrub tool that could serve as a starting point:

http://labs.hoffmanlabs.com/node/426

The acl_scrub tool does ODS-2, but could be extended for ODS-5.

[Jess Goodman]

I've used MCR PWRK$DELETEACE to delete pathworks ACLs on a few files, but its user interface is so bad that it is very ugly to use it in a script.

* It ignores any command line
* It prompts for the file name but gives no error no matter what garbage you might type in.
* It then always asks five Y/N questions about which ACEs to delete; again it accepts any garbage.
* It ignores and end-of-file and just keeps on prompting. You must enter "x" to cancel or exit. So if run from a script and you don't have "x" in the right place it will go into an infinite input loop.

Obviously not written for VMS originally, but on what OS is this an acceptable design?

With that all said, if you put the below commands in a .COM file, and call that .COM file from another, with a target file as the P1 parameter each time, it should work.

$ DEFINE /USER TARGET_FILE 'P1'
$ MCR PWRK$DELETEACE
TARGET_FILE
Y
Y
Y
Y
Y
x
$ EXIT

[Mike Kier]

Just an oddball idea, but can you set up a dummy file with the ACEs you actually want and then do a SET SECURITY /LIKE from it to your pathworks files?

[John Gillings]

Jeremy,

I think Mike's on the right track. I seem to remember some tricks with SET SECURITY/LIKE. Either it would delete everything before copying the new ACL (in which case you can use it to wipe the whole ACL using a file with a null ACL as the source) or it would skip hidden ACEs. If the latter you could preserve all the "normal" ACEs using a temporary file, set it /LIKE the PWRK file to strip the hidden ACEs, then back the other way to restore the visible ones.

I've attached a procedure exploiting Jess's suggestion with a pipeline to feed in the files. P1 is a wildcard filespec, including any DIRECTORY selection qualifiers. For example:

$ @DELETE_PWRK_ACE *JEREMY*.*/BEFORE=YESTERDAY/SINCE=1-JAN

Since I don't have any PWRK files or a copy of PWRK$DELETEACE to test it on, please check first...

(On the other hand, if someone can get hold of the source of PWRK$DELETEACE it can't be too hard to wrap it into a decent interface!)

[Jon Pinkley]

Jeremy stated that an IA64 version of PWRK$DELETEACE.EXE wasn't available.

Concerning Hidden ACEs, it appears that SECURITY privilege is required to delete a hidden ACE with the DCL command SET SECURITY.

from http://h71000.www7.hp.com/doc/83final/6048/6048pro_001.html

Hidden Indicates that this ACE should be changed only by the application that adds it. Although the Hidden attribute is valid for any ACE type, its intended use is to hide Application ACEs. To delete or modify a hidden ACE, you must use the SET SECURITY command.
Users need the SECURITY privilege to display a hidden ACE with the DCL commands SHOW SECURITY or DIRECTORY/SECURITY. SECURITY privilege is also required to modify or delete a hidden ACE with the DCL command SET SECURITY. The ACL editor displays the ACE only to show its relative position within the ACL, not to facilitate editing of the ACE. To create a hidden ACE, an application can invoke the $SET_SECURITY system service.

Protected Protects the ACE against casual deletion. Protected ACEs can be deleted only in the following ways:
By using the ACL editor
By specifying the ACE explicitly when deleting it
Use the command SET SECURITY/ACL=(ace)/DELETE to specify and delete an ACE.

By deleting all ACEs, both protected and unprotected
Use the command SET SECURITY/ACL/DELETE=ALL to delete all ACEs.

The following commands do not delete protected ACEs:

SET SECURITY/ACL/DELETE
SET SECURITY/LIKE
SET SECURITY/DEFAULT
Nopropagate Indicates that the ACE cannot be copied by operations that usually propagate ACEs. For example, the ACE cannot be copied by the SET SECURITY/LIKE or SET SECURITY/DEFAULT commands.
None Indicates that no attributes apply to an entry. Although you can create an ACL entry with OPTIONS=None, the attribute is not displayed. Whenever you specify additional attributes with the None attribute, the other attributes take precedence. The None attribute is equivalent to omitting the field.