Operating System - OpenVMS
1748011 Members
3981 Online
108757 Solutions
New Discussion

Re: Java/VMS - Cannot transparently delete a subdirectory. wityh NETMBX, TMPMBX privileges

 
SOLVED
Go to solution
Ph Vouters
Valued Contributor

Java/VMS - Cannot transparently delete a subdirectory. wityh NETMBX, TMPMBX privileges

Dear Java/VMS user,

 

I thought best to document this pure Java/VMS aspect at http://vouters.dyndns.org/tima/OpenVMS-Java-Directories_deletion_w_o_the_BYPASS_granted_privilege.html

 

This peticular aspect impacts every Java based code running on OpenVMS. This includes Apache/Ant, Apache/Maven, JRuby among a few. Every Opensource code underneath executing for the same purpose the DECC$RMDIR function is not impacted by this problem. This is highlighted in this technical paper.

 

Because this problem impacts all Java based Opensource code I thought best to change the title of this document to:

[OpenVMS, Java] Java based Opensource codes may reveal unportable onto OpenVMS

which better reflects the reality to my mind.

 

This issue is 100% a pure Java for OpenVMS issue and does not impact  other Oracle's based Java .implementations running on other operating systems.

 

You may find this technical article overdocumented. I have been desperatly trying to find a possible solution to the problem. The evidence is that there is currently none unless granting the BYPASS privilege (may not be desired) or manually changing the protections with $ SET FILE/PROTECTION=(O:RWED) subdir.DIR (which is very cumbersome). The other possible solution I would think of would be to VMS INSTALL the Java image granting it the BYPASS privilege.

 

Regards to everyone,

Philippe

9 REPLIES 9
Hoff
Honored Contributor
Solution

Re: Java/VMS - Cannot transparently delete a subdirectory. wityh NETMBX, TMPMBX privileges

If I've guessed correctly at what you're reporting here with Java, have you tried selecting the DECC$FILE_PERMISSION_UNIX or JAVA$CREATE_DIR_WITH_OWNER_DELETE logical names to modify this behavior?  Also review the current settings of the JAVA$DELETE_ALL_VERSIONS and JAVA$RENAME_ALL_VERSIONS logical names while you're looking at this area.  Check the HP/Compaq OpenVMS Java docs for related details.

Ph Vouters
Valued Contributor

Re: Java/VMS - Cannot transparently delete a subdirectory. wityh NETMBX, TMPMBX privileges

$ dire maven.dir
%DIRECT-W-NOFILES, no files found
$ sho proc/priv

 7-OCT-2011 23:00:24.54   User: PHV              Process ID:   202C2A33
                          Node: THESEE           Process name: "PHV"
 
Authorized privileges:
 ACNT         ALLSPOOL     ALTPRI       AUDIT        BUGCHK       BYPASS
 CMEXEC       CMKRNL       DIAGNOSE     DOWNGRADE    EXQUOTA      GROUP
 GRPNAM       GRPPRV       IMPERSONATE  IMPORT       LOG_IO       MOUNT
 NETMBX       OPER         PFNMAP       PHY_IO       PRMCEB       PRMGBL
 PRMMBX       PSWAPM       READALL      SECURITY     SETPRV       SHARE
 SHMEM        SYSGBL       SYSLCK       SYSNAM       SYSPRV       TMPMBX
 UPGRADE      VOLPRO       WORLD
 
Process privileges:
 NETMBX               may create network device
 TMPMBX               may create temporary mailbox
 
Process rights:
 PHV                               resource
 INTERACTIVE                      
 LOCAL                            
 PHV_GROUP                        
 APACHE$APR_ALL                   
 APACHE$READ                      
 APACHE$EXECUTE                   
 
System rights:
 SYS$NODE_THESEE                  
$ define JAVA$CREATE_DIR_WITH_OWNER_DELETE true
$ java "MkdirRmdir" maven
Fatal - Directory still exists
Warning - Calling deleteOnExit()
$ dire maven.dir
%DIRECT-W-NOFILES, no files found

Post-Scriptum: I  do not much appreciate this inflation of JAVA$* and DECC$* logicals. This does look to me as poorly designed software leading the end-user to many questions, trials and complete loss of time and efforts. This only proves very end-user unfriendly and does not deserve much of my consideration.

Anyhow, thanks to Hoff to bring in this solution,.

Ph Vouters
Valued Contributor

Re: Java/VMS - Cannot transparently delete a subdirectory. wityh NETMBX, TMPMBX privileges

Exclusively thanks to Hoff's input, the corresponding article in my knowledge database has been completely rewritten, simplified and split into two documents each one dealing with one subject although both having to be applied the exact same logical settings so that the code works under minimal privilege conditions.

 

You may read the result of these changes, redeading :

http://vouters.dyndns.org/tima/OpenVMS-Java-Directories_deletion_w_o_the_BYPASS_granted_privilege.html

and

http://vouters.dyndns.org/tima/OpenVMS-Java-Using_the_Java_Security_Manager.html

 

As a fallout of Hoff's input, I modified this Maven related article at http://vouters.dyndns.org/tima/OpenVMS-Java-Maven-Ant-Invoking_Ant_from_within_Maven-Solution_when_running_custom_Ant_version.html in its OpenVMS specific note subparagraph (in the the NOTE ATTENTION THE READER paragraph).

 

Also as a fallout of Hoff's input, this implies the two persons who ported JRuby onto OpenVMS (this includes myself) must add this logical with this setting within each provided JRuby's DCL command files as well as within the GNV bash provided Unix shell script so that JRuby works as Ruby advertises it.

 

As well and as a fallout of Hoff's input, the HP supplied ANT.COM available on HP's Web site has to also include this logical with this setting for correct Ant operations at the DCL prompt.

 

Several Kudos to Hoff.

 

I may write some code in a near future in order to extract each JAVA$ logical name from the Java's user_guide.html. With the knowledge of each possible Java$ logical name, this will better orient me toward a possible solution as I will know what I am looking after within this Java User Guide or any other Web available documents. Such a summary already exists for DECC$ logicals (refer to the sample C program at http://vouters.dyndns.org/tima/OpenVMS-DECC-Getting_the_logicals_DECC_list.html).

 

Regards,

Philippe

H.Becker
Honored Contributor

Re: Java/VMS - Cannot transparently delete a subdirectory. wityh NETMBX, TMPMBX privileges

>>> Post-Scriptum: I  do not much appreciate this inflation of JAVA$* and DECC$* logicals. This does look to me as poorly designed software leading the end-user to many questions, trials and complete loss of time and efforts. This only proves very end-user unfriendly and does not deserve much of my consideration.


I'm sure you are not the only one who is not happy with all the DECC (really CRTL) and Java (really Java VM) feature logicals. But, you are switching between VMS and Unix behaviour. That requires you to turn some knobs or throw some switches. Usually you need the Unix behavior just for one image. The right thing to do is to enable the Unix behavior at image initialization. If this wasn't done by the developers, for whatever reason, the only option is to enable the feature at DCL level before running the image. You do not have control over the image initialization of the Java VM,  so you have to stick with enabling features at DCL level.
And no, the CRTL or Java VM developers can't change the default behavior, it would break older applications. VMS is very good in upward compatibility and that is very much appreciated by many customers.
If you use a logical, always try to define it in user mode. That should almost always work and should not have any effect on subsequent commands/images.
Ph Vouters
Valued Contributor

Re: Java/VMS - Cannot transparently delete a subdirectory. wityh NETMBX, TMPMBX privileges

Dear Hoff,

 

I named you as the hidden technical contributor of my three above mentionned articles. Provided you wish to receive a copy of the orginal documents in text form for your use and eventually for advertising your company if any as well as promoting your competence, let me know by dropping me a mail at the mail address you will find on my home page at http://vouters.dyndns.org/ In any cases, I remain responsible for what I publish on my Web site.

 

If you are Steve Hoffman I worked with during my DEC, Compaq, HP career and you hold the Hoffman Labs Web site, please do correct your statements regarding my Web site. Every article contained there is my personal contribution to TIMA/Qtip/Saw DEC's, Compaq's, HP's knowledge databases and does in no case includes a copy of other DEC's, Compaq's, HP's employees work although I pastly sometimes when still employed inspired myself for some of them from relevant code extracts  to simplify my work producing code.

 

Since January 2010,  I have no longer any connection with HP and does in very rare occasions gets support from an HP employee. This is although my Web site and the technical articles it contains are often still accessed by HP employees as a reference for either their own use or for supporting HP customers.

 

With my renewed thanks for your post as a reply to mine which will undoubtly help many Java/VMS users as well as VMS system managers .

Philippe

Hoff
Honored Contributor

Re: Java/VMS - Cannot transparently delete a subdirectory. wityh NETMBX, TMPMBX privileges

That portion of the discussion beyond Java is best conducted offline, though updates have been made.

 

John Gillings
Honored Contributor

Re: Java/VMS - Cannot transparently delete a subdirectory. wityh NETMBX, TMPMBX privileges

Phillipe,

 

   This is not just a Java issue, it's true of deleting directories from anywhere.

 

  Some history might explain some of the logic. Way back in V1.0, the check for an empty directory was not implemented. Since deleting a non-empty directory results in lost files, the quick fix was to always create directories without D access for anyone. The non-empty check was implemented in VMS V2 (or V3?), and at that time, the system COULD have changed the "no D access" default to use the general file protection default, but it didn't happen, no doubt because of intertia.

 

  So unless a directory is created with explicit D access, the protection will need to be changed before it can be deleted, regardless of what language you use (up until fairly recently the D access was even stripped from an explicit CREATE/DIRECTORY/PROTECTION=mask!). 

 

> The other possible solution I would think of would be to VMS INSTALL the Java image granting it the BYPASS privilege.

DEFINITELY POSITIVELY NO! NO! NO!

 

This would allow anyone using Java to delete any directory, or, broader, to access anything. It would effectively break all protection across the system.

 

JAVA$CREATE_DIR_WITH_OWNER_DELETE is a possible candidate for a system wide logical name. Indeed, I'd like to see a system parameter (like RMS_FILEPROT) or a SET SECURITY command which could set the system or process wide default protection for directories to fix this anachronism.  

A crucible of informative mistakes
Ph Vouters
Valued Contributor

Re: Java/VMS - Cannot transparently delete a subdirectory. wityh NETMBX, TMPMBX privileges

John,

If you did notice it, I demonstrate in my paper I can delete my own created subdirectories that I do create with CREATE/DIR (no other options) with just NETMBX and TMPMBX privileges using an simple rmdir HP CRTL call. The created subdirectory I can delete with an rmdir call has just the (RWE,RWE,RWE,RWE) directory protections.

So this leads to my statement in my conclusion chapter :
<QUOTE>
Provided the Java/VMS
calls the HP VMS/CRTL rmdir function like on any other Oracle's based Java implementations, this JAVA$CREATE_DIR_WITH_OWNER_DELETE logical would have strictly no reason to exist and this aspect would be totally transparent to the Java/VMS end-user.
</QUOTE>

Warmest regards to you,
Philippe
Hoff
Honored Contributor

Re: Java/VMS - Cannot transparently delete a subdirectory. wityh NETMBX, TMPMBX privileges

The behavior of C may well depend on Unix compatibility knobs already set elsewhere in the process or system context, and (if not) I'd tend to expect (and if any changes are ever made as a result of this discussion) code changes in the CRTL for the addition of the DECC$CREATE_DIR_WITH_OWNER_DELETE to cause rmdir to honor VMS protections, unless the logical name is established.

 

But then, which behavior is correct here is entirely HP's call.