Forum OpenACS Development: Registered users can read private procs in api-doc

I tried to post this as a bug in the bugtracker a few minutes ago, but kept getting an error. This is a suggestion more than a bug.

Report follows:

Steps to Reproduce

Browse to /api-doc/

Actual Results

Users of a default openacs site can read the source of private procs.

Expected Results

Only admins should be able to read source of private procs. Or, make this a parameter switchable feature.

Discussion

This is especially important for cases where a site has customized code:

1. that may introduce vulnerabilities
2. that seeks to use customized security code not expected to be viewable by registered users (or public)

Currently, the method to prevent reading is to limit access of the local api-doc to admins.

Manually coding the above suggested feature could risk having the code inadvertently overwritten during a site upgrade.

The suggested, more fine grained change would permit publishing of useful code in context of documentation and promoting OpenACS dependent apps (and subsequently OpenACS) on the same site as apps are deployed, without making a site extra vulnerable.

As a use case, consider if OpenACS were used in some kind of cryptocoin value-added service where some private procs calculated location of wallets in the file system.

Thanks kindly,
Ben

Collapse
Posted by Benjamin Brink on
ps. I'm not familiar with the Next/xotcl2 system, but am guessing that something like this may be applicable to its analog of api-doc --especially if my limited understanding is accurate: That each object is essentially a proc.
Collapse
Posted by Gustaf Neumann on
Thanks for reporting a problem with the bug-tracker ... which was not easy to fix: the problem was that the vulnerability scanner has semi-inserted some values into the bugtracker, which blocked the generation of new entries.

One problem with the bug-tracker is the way, how it determines the names of the cr-items, which is very crude (and as this example shows) not fail-safe. One other problem is, that this semi-insertion should not be possible....

However, i have fixed the contents in the database, fixes a few other minor issues and modernized the SQL procedures and functions to make these more readable. Let us hopwe, this works for the next ten years.

Concerning your question: the "private" modifier of ad_procs has nothing to do with security. It can be called from every other package, it can be introspected, etc. The only purpose it has for ad_procs is to denote a developer an intended usage.

btw. it is not correct that xotcl/nsf objects are "procs", these are tcl commands (c-implemented functions).

What kind of problem are you addressing? Do you have passwords etc. in your ad_procs? The easiest thing is then do restrict the access to the API-browser to admins/swas or whatever is appropriate.

Collapse
Posted by Benjamin Brink on
Gustaf, if ever there were an Olympic competition for debugging, surely you would win at least ten years of Gold. Thank you.

And thank you for correcting my wild and reckless expression of xotcl objects; The falsehood is proof that my casual interpretation of xotcl snippets in context of generic tcl is not a practical method of learning.

Also, I'm sorry you felt it necessary to repeat to me how the "private" modifier of ad_proc is not for security. The previous time, I was trying to hide some code from other parts of the system.

What kind of problem are you addressing?

In this second case, I'm trying to find a long-term, stable compromise between:

1. integrating ad_proc's api-doc documentation with package documentation published via /doc

2. hiding some site installation specific modified security code so non-admins/swas cannot read it. Yeah, a more complex scenario of passwords in ad_procs;

Instead of passwords, its code that encrypts sensitive user info stored for use in context of the system that must occasionally be decrypted again (instead of the usual comparing of one-way algorithms).

You are right, the current solution is to limit access of /api-doc to admins (on an ecommerce site for example), and publish generic documentation accessible to all users on another site (such as OpenACS.org).

This is acceptable, if I am the only one using this new ecommerce package. However, the package is intended for others.

As a package developer, I would be remiss if I didn't at least try to find a way to have an equivalent solution incorporated into OpenACS by default, since the cost of changing a system after deployment for just one case might be so much higher than overcoming the hurdle of adding a subtle revision to OpenACS to begin with.

Also, it would be convenient if sensitive code could be hidden on early adopting sites while providing a reasonable amount of api documentation that helps promote the package. --a way to promote OpenACS and packages without duplication in resource costs etc.

As I type this, I think I figured out a fallback solution:

Add some code to a tcl/sched-init.tcl file that checks permissions for api-browser, and forces admin access only. (And make a separate site to promote app.)

Other ways I thought about exploring:

A. define the procs outside of ad_proc, or as apps outside of OpenACS.
B. add a "hide" argument to ad_proc so API browser doesn't publish to non-admins.

I supose option B would have too much impact on the system to consider adding to OpenACS even if a patch is submitted (subject to refactoring).

Collapse
Posted by Benjamin Brink on
The solution is to assign the encrypt and decrypt proc names to a parameter which gets called by safe_eval. That way, the procs may be something other than the default ones included in the package.