A few thoughts about the security manager: it exists to allow for supervising running Rexx programs.
There are sensible instructions/actions in the language that could be exploited in a malevolent
manner; one can mitigate this by appointing a security manager to determine how to handle them.
Sensible instructions/actions are calls to external routines or commands, access to stream-related
built-in functions (charin, charout, chars, linein, lineout, lines, stream), requiring (calling)
packages/programs, access to any protected method, and access to the environment directories .local
and .environment.
All of this has been working in ooRexx since its existence; ooRexx 5.0.0 broke the supervision of
static requires directives, and it still does not work, which makes the whole concept of a security
manager moot, it seems.
Looking at the security manager-related APIs, there are three classes that possess a
setSecurityManager method: .routine, .package, and .method. How about adding an optional new
trailing "securityManager" argument to their constructors? Supplying it would cause the supervision
messages (CALL, COMMAND, STREAM, METHOD, REQUIRES, LOCAL, ENVIRONMENT) to be sent to the supplied
security manager. Could that mitigate the situation regarding REQUIRES?
---
Another concern is that the setSecurityManager method is not protected. This allows a code block
(from a routine, method, or package) to use it to set/change, or remove a security manager.
---
When experimenting with this ability (to change the security manager from within the supervised code
block), the following observations were taken:
* the security manager of the supervised code block wil get the supervise
messages CALL, COMMAND,
STREAM, METHOD, REQUIRES (for dynamic requires only!), LOCAL, ENVIRONMENT
* removing the security manager of the supervised code block by sending
".context~executable~setSecurityManager": this affects the supervise
messages CALL, COMMAND,
LOCAL, ENVIRONMENT, and STREAM, which do not get sent anymore. However, the
supervise messages
METHOD, REQUIRES still get sent to the originally set security manager,
which seems to be a bug
* adding a new security manager to the code block by
sending ".context~executable~setSecurityManager(.allowAll~new)": this
affects the supervise
messages CALL, COMMAND, LOCAL, ENVIRONMENT, which get sent to the new
security manager. However,
the supervise message STREAM does not get sent to it; the supervise messages
METHOD, REQUIRES
still get sent to the originally set security manager, which seems to be a
bug
So something is wrong when changing the security managers for code blocks depending on the supervise
messages:
* the original security manager for the supervise messages METHOD, REQUIRES
does not get changed
* the supervise message STREAM, once the security manager got removed, does
not get re-established
to a newly set security manager
---
It is interesting to note, and potentially a bug, that accessing some environment symbols are not
supervised (neither the LOCAL nor the ENVIRONMENT supervise message gets sent), e.g. .Object, .true
---
So there are different aspects in this context that need to be thought about,
checked and fixed.
Any thoughts about this? Any comments, ideas how to proceed from here on?
Also, how about the terminology used here (supervise messages that get sent to a security manager),
is it understandable, clearer, easier than the current documentation?
---rony
On 12.07.2026 18:56, Rony G. Flatscher wrote:
Whenever I have some free time I try to work on an update of my book "Introduction to Rexx and
ooRexx", which I wrote more than thirteen years ago to bring it up to ooRexx 5.2.0.
At the moment I am working on a new section about the ooRexx "Security Manager", explaining the
security manager protocol and how to use it. This is a very nifty and very useful feature in ooRexx.
The agent.rex example in rexxref.pdf (Example 13.1. Agent Program) in the section "Chapter 13. The
Security Manager" employs a "::requires json.cls" directive, which should be reported with the
"REQUIRES" message to the currently active security manager. This is not the case, which is a
serious bug. Cf. <https://sourceforge.net/p/oorexx/bugs/1422/> or
<https://sourceforge.net/p/oorexx/bugs/1886/>.
Attached there are three files:
* launcher.orx: accepts the name of a program to supervise; demonstrates how
a running package
can have a security manager assigned to it
* myProgram1staticRequires.orx: this is basically the "agent.rex" program
from rexxref.pdf which
employs a static requires ("::requires json.cls"), which ooRexx does not
report to the
security manager
* myProgram1dynamicRequires.orx: this agent.rex variant employs a dynamic
requires in which case
the REQUIRES messages get sent (two actually, the first with the
unqualified name, the second
with the fully qualified name)
To run:
launcher.orx myProgram1staticRequires.orx
launcher.orx myProgram1dynamicRequires.orx
The static version does not report REQUIRES messages, the dynamic version does. The normal case in
ooRexx programs are static requires.
The question is whether this serious bug can and will be fixed in a timely manner, such that I can
point out in the book, that maybe future versions of ooRexx would have the appropriate fix? (The
book is slated for late September, early October of this year.)
Any comments? Maybe ideas about possible fixes that could be sought? Or: what should I write in my
book about ooRexx' security manager?
---rony
P.S.: The documentation of the security methods in the security manager section "Chapter 13. The
Security Manager" of rexxref.pdf is wrong, as the return values got mixed up (.true and .false
reversed) which is quite irritating, will open a documentation bug for it.
_______________________________________________
Oorexx-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/oorexx-devel
