Creation password at runtime

[Bruce Easton]

> -----Original Message-----
> From: Bruce Easton [mailto:bruce at stn.com]
> Sent: Friday, January 19, 2007 5:30 PM
> To: filepro-list at lists.celestial.com
> Subject: RE: Creation password at runtime
>
>
> Any thoughts to my ealier suggestion of an enhancement to fp?
> (edited for emphasis)
>
> . . .
> > where a combo key of processing table name + creation password
> (CP) could be
> > stored in a new special key - say "cp_ok_key" and that could ALLOW THE
> > DEVELOPER TO PRE-AUTHORIZE LOOKUPS into
> creation-password-protected files.
> >
> > i.e., you're in rcabe and
>
> > UPON SAVING THE TABLE, a NEW OPTION when selected would allow you
> > to enter one or more filenames, and for any filenames that
> > are password protected,
>
> > the password would be prompted, and if it is
> > validated, an entry is made into the "cp_ok_key" special file
> (usable only
> > by *cabe,*clerk,*report). Then at runtime, before asking for a CP for a
> > variable-name file, before asking for a CP, this special file
> is checked for
> > the table name-filename combo. If it's there, then no need to
> ask CP again.
> > I don't think backward-compatilbility would be a problem with
> this, but then
> > again, I haven't thought much about the level of automatic maintenance
> > something like this should need from the cabe and clerk programs.
> >
> . . .
>
> My only problem now that I look at this again, is
>
> 1. filepro's auto-maintenance of this file - what would that be
> like?? and
>
> 2. it seems like it could be spoofed - i.e., someone seeing
> somehow a table that gets thru to seeing/updating a file that
> they want access to (that they are not supposed to have) and then
> temporarily moving the table out of the way and slipping their
> own table in place.
>
> But, regarding #2 above, maybe this special new file could hold:
>
> 1. filepro file name that has the creation password
> 2. table name (that is currently being saved
> 3. sum / byte count - something that can be compared to the
> current table running
>
> So "cp_ok_key" would become a standard part of your filepro
> files, just like key, data, lockfile, etc.  If it's not there,
> the program works as it does now (backward compatibility).  If an
> entry in "cp_ok_key" does not match exactly as it should with
> what is being used at runtime (the current table where a var.
> lookup is in question), then the program works exactly as it does
> now.  But if the entry matches exactly, then a creation password
> is not asked at runtime.
>
> So you might have entries (encrypted though for use only by fp)
> in this new type of fp file for my original example like:
>
> APP,mytablename,4355
> OTHERFILE,mytablename,6234
> YETANOTHERFL,table4,3244
>
> where APP is the filepro name with the creation password
> where mytablename is the table name
> where 4355 is a sum or byte count when the table was last saved
>
> So in the above example, mytablename is pre-authorized to do
> lookups into APP and OTHERFILE with respective sizes 4355 and
> 6234 without asking for a CP at runtime.
>
> Wish I could come up with something simpler for something that
> doesn't seem to come up much - but I'm trying to think about
> building on what is in place now. With the addition of an
> optional new type of filepro file, this obviously would require
> mods to cabe (to ask the new additional question and store data
> in the new file) and clerk (to check the new file if there and
> act accordingly).
>
> Bruce Easton
> STN, Inc.
>
Oops - flawed myself.  Above, for what I am suggesting, the sizes for:

> APP,mytablename,4355
> OTHERFILE,mytablename,6234

should be the same since they are against the same table name, and related,
where I say:
> So in the above example, mytablename is pre-authorized to do
> lookups into APP and OTHERFILE with respective sizes 4355 and
> 6234 without asking for a CP at runtime.

the sizes should be the same there as well, since I am intending that the
size is the size of the processing table to be checked against the current
size.

Bruce

Bruce Easton
STN, Inc.