Creation password at runtime

[Bruce Easton]

(comments posted inline, primarily in response to Jay Ashworth's post)

> Joe Chasan wrote on Monday, February 05, 2007 8:38 AM:
> 
> On Sat, Feb 03, 2007 at 02:53:01PM -0500, Jay R. Ashworth wrote:
> > On Fri, Jan 19, 2007 at 10:02:14AM -0500, Cesar Davila Jr wrote:
> > > I've been working on this with Bruce and we understand what 
> you are saying
> > > and agree with it. So we did as suggested and placed the 
> lookups in the
> > > processing tables without the variable names so that we can 
> be prompted for
> > > the creation passwords when we tokenize.
> > > 
> > > What we are encountering is that the user is being prompted 
> for the creation
> > > password when they start using the application. The users are 
> not "creating"
> > > anything other than data. In fact, the application Bruce is 
> working on is
> > > simply trying to browse a series detail files.
> > 
> > I believe those two paragraphs are contradictory, alas.

Jay - yes they are.  However, if you read my posts subsequent
to the one you've referenced on this topic, I think you will 
discover that I do NOT agree with the current design and behavior. 
You've replied to something that had a fair amount of discussion 
and consideration since Cesar's post.

> > 
> > A creation password is prompted for when a lookup to the file it
> > protects is "bound" by filepro.  With fixed-named lookups, that binding
> > happens at compile time.
> > 
> > With variable-named lookups, that binding does not happen until
> > runtime.
> >

Yes, I think most of us can now see that is the current method 
and behavior.  I contend that any checking/handling/"binding"/
what-ever-you-want-to-call-it of creation authority, thereby 
prompting for Creation Passwords at RUNTIME is WRONG.  It makes, 
as I've pointed out, filePro's original definition of the purpose 
and usage of the Creation Password misleading.  As a developer, 
you cannot produce code with variable-named lookups, tokenize it 
and sell just the tokenized software to a client without the 
client's end-users getting prompted at runtime for creation 
passwords.  

Passwords that you may not want the client to know 
at all, and/or that the client probably does not want to be 
bothered with.  And, asking for these passwords at runtime, 
introduces authority decisions for the client regarding format 
protection and their personnel.  The client now has to keep track 
of who (people that come and go) knows creation passwords that 
were created by (and probably only for) the developer.  To me, 
going near any of the runtime programs with this check is bad.  
And if someone really wants to use Creation Passwords in this way 
at runtime, then, please, at least call it something else.

> > I understand your problem, but I also understand their implementation,
> > and I see why the other requirements of their implementation lead to
> > this requirement.

Yes, I think maybe I can understand how filepro arrived at 
this behavior.  Let's jump back for a moment to filepro prior 
to 4.8, where you had quickstart and creation passwording, 
but no variable name-lookuping.  The creation password checking 
that was only manifesting itself in creation programs was working 
as advertised, but really had the additional feature (to me, 
more than what was defined in the manual) of protecting views 
of data via lookups.  Had nothing to do with protecting formats 
as advertised, but by having this added feature, together with 
passwording screens, menus, etc. could sort of protect views of 
the data via lookups between even different developers in the 
same shop.  And it could do so without even having to store 
anything extra besides the creation password in the maps - I think 
that part was neat for what it offered.  But the original 
advertised definition and purpose, in my mind was already askew 
when it came to lookups, again, since part of filepro's definition 
of the Creation password is "This password does not, however, 
affect who can or cannot see and change your records - runtime 
operations are protected separately with individual passwords." 
(3.0 manual)  Therefore, even under *cabe, how does asking for a 
Creation Password (CP) when looking up from another file jeopardize
the formats or file structure of the file (map/out/prc/screen, etc.) 
that has the CP?  It doesn't. One has to argue that the lookup
in the file that is looking into the file with the CP is itself
a format of the file that has the CP.  I can live with that.  But
it's purpose is now protecting viewing of data, not being able to
alter any formats nor file structure that reside in the filepro
directory of the file that has the CP.  I'm fine with that too, 
because, as a developer, you can live with it and keep it away
from runtime clients.  It is when we try to bring this prompting
of the CP over to the runtime programs that I have a problem.

So until this newer behavior with the advent of variable-named 
lookups, the lookup behavior of CPs in *cabe has served well for 
certain applications. (Say developing software for in-house use, 
but even then, as John E. pointed out, if people "in-house" can get 
to vi key files and such, then it's easy to get around that type of 
application of creation passwording.  And if you only allow certain
users controlled menu access to your system, and no development 
functions, then you don't even need to bother with CPs.  So I guess
the really bad idea of introducing prompting of creation passwords 
at runtime was to not create a data security loophole with the 
advent of variable-named lookups; moving foward along on a track to 
me that was already off-course for the sake of consistency and 
backward compatibility - fine.  And I am certainly happy that the 
implementation of variable-named lookups did not take longer than 
it did.
     
> > 
> > And, honestly, I don't see any way they can satisfy those requirements
> > and not cause this problem.

Well, what Joe wrote below, which was suggested previously - very 
neat, very simple, is one of a few suggestions that you may have 
missed.  One, which I had suggested, calls for the *cabe program to 
allow the operator to ask to be prompted for files that do not have 
hard-coded lookups in the table - and for each of those files, to 
then prompt if necessary for a creation password.  I think I called 
it "pre-authorization." (If interested, see earlier posts regarding 
how this could be done and how it could be backward compatible.)  But 
what is below, I would think, is all that is needed, especially since 
I view this as a patching something that has already headed in the 
wrong direction.  If protection of viewing/updating data is the 
concern, then as others have indicated, there is a lot more to 
consider than just the prompting of some password at runtime.

> 
> if the lookup exists elsewhere in the prc table in hardwired form, then
> lookup to same filepro file or filepro file/qualifier combo using a 
> variable can be excluded from such checks.  this satisfies both 
> requirements but apparently would have to be a wishlist item for 
> a future change/release as it is not coded that way right now.
>

Joe, thanks for reminding us of this simple idea that John had 
thought was already in place.  Hopefully, if it is implemented, 
it will be done so that the hard-wired lookup just needs to be 
scanned by *cabe and doesn't have to executed by the program.


Bruce Easton
STN, Inc.