Re: SYSTEM(14) with D3

Some final footnotes, below... (after that, i think i'm COMMONed out);
the bottom line is... this has the makings of support nightmares.
There's also ways to fix it so that it doesn't impact the small
minority that might desire to utilize common across LOGTO-s.

Tony Gravagno wrote:
[snip]
I understand what he's saying about bug-vs-feature but this
functionality could have gone either way. If I open a file in one
account and I actually want to reference it in another account, I
shouldn't have to re-open it. To get to another account we use
something like:
execute "logto acct":@am:"do.something"
A sub-footnote here is that the documentation states that on an
EXECUTE, the "@am" is merely an alternative to a "DATA" statement.
However, the "do.something" on a DATA statement will instead perform
such action in the context of the original acct vs. the target
account.(I'm almost certain this is a regression and that DATA used to
work the way "@am" does -- which would then be consistent with the RD
docs.)

When I come back I expect named common to be exactly as it was.
Funny thing here, tony... your "as it was" is in fact NOT GUARANTEED.
The remote account you logged to could have easily stepped on the Named
Common for you. (Hopefully you're not implying that NAMED-COMMON is
not returned.) Alternatively, you may have delayed-initialization as
to how you use named-common, with the remote account actually doing the
"initialization" of the named common, and instead of having the common
"exactly as it was" (ie. returning with an 'uninitialized version') --
you unwittingly inherit an initialized environment.

Trust me... I totally get how to take advantage of this.. as do most in
this thread. It is only that I can foresee how one can more quickly be
CAUGHT by this, too -- and even the most learned! (see below.)


From
a design perspective he's suggesting that in the new account we need
to re-initialize common. When I come back do I need to re-init again?
One can immediately imagine a stack where we push the current
environment, do the logto, then pop on return - hell, this is what we
used to do before we had the Execute/Perform statements. As you see,
this is just getting more cumbersome by the minute.
Consideration noted, but don't go off there... Any built-in
functionality associated with the nuances of
passing/returning/not-passing/not-returning a process' context as part
of the EXECUTE functionality is normally handled transparent to the
programmer without creating any additional requirements for default
behaviors. (Such architectural/design decisions are regularly dealt
with in other aspects of the EXECUTE functionality: do i pass/return
LISTs across execute-levels?; do i pass/return output streams and
related i/o states (eg. "RETURNING"-clause)?; do i pass/return stacked
data?; what to do if the user logs OFF on a lower layer? -- these are
dealt with by design (some as options w/defaults) -- but are all
implemented to be largely transparent.)

Speaking of "RETURNing" things that shouldn't -- don't you just love
that a FLASHBASIC "ABORT" in a subroutine now does a RETURN instead of
an A-B-O-R-T !!! >> -- does this fall into "it's documented that way";
it's been working that way for awhile; some people want it to work that
way; we didn't know what else to do with the ABORT???


In fact, the doc is quite explicit about this:
"named common: FlashBASIC variable space used to store
variables and arrays in the 'id'entified area which is only
initialized at logon. Global common space is common for all levels of
the same process (i.e., level pushes, executes, filetime bridges &
indexes, etc.)"

So, named common survives level pushing and executes, which is exactly
what's happening when we Execute a Logto from BASIC.
A "consistency"-argument here may not be a good one ( ie. just because
"EXECUTE LOGTO" vs. "LOGTO" behave the same way), since most
bugs/failures in the system will also behave the exact same way when
doing an "EXECUTE" of them. :)

In this case I
think the doc does an adequate, though not great job of defining the
expected behavior for someone who is familiar with the environment.

What is not clear here, though implied, is that even when your program
ends your named common survives. The doc doesn't say named common
only lasts as long as you're still executing within the BASIC Runtime,
it says it's initialized at logon. It continues to survive across
logto from TCL and execution of other code - because we still have not
gone through a full logoff/wrapup. In this respect someone might run
a program later and say "whoe, I just started running these programs,
why are my variables already initialized?"

In this case, yes, this is
a double-edged sword. But this is not a bug, it's useful behavior
that was defined over a decade ago. The solution that was implemented
wasn't "wrong", it was just one of a couple possibilities, and I
happen to enjoy the way it works now.

This is more a single-edged sword that to your point still hurts no
matter how you're hit with it! -- especially since the fact the
functionality appears to have been this way for a considered time...
However, i don't think you can remotely compare the potential damage
from the front-edge of this sword to the back-side.

My HAT must lean towards "support", especially when considering the
following all-to-COMMON scenario (no pun) :

Suppose you have a completely stand-alone production ACCOUNT that you
ultimately save/restore into some backup account (perhaps used as an
"archive"... or, perhaps used as the "development environment" for the
next generation of the product... or, perhaps used as a model for a
"second user account") -- all otherwise self contained... all working
fine! Perhaps all using NAMED-COMMON (or NOT... I don't know, it's
been too long... original programmer not here...what not...) In
general, you are having NO problems! Perhaps even for years!

For a moment... forget any "programmatic" "LOGTO" behaviors...

T-H-E-N, go figure that in simply performing a LOGTO (from TCL)
between any of these otherwise assumed stand-alone environments (maybe
only momentarily visting another on a temporary validation basis) -- as
a result of LOGTO actually working the way "[some] happen to enjoy"...
I might now be experiencing severe data-corruption;
program-interruptions; erroneous application behavior (perhaps
detected/perhaps not) -- simply based upon NAMED COMMON and whether the
subject-LOGTO-anomaly was originally considered. The funny thing is...
these considerations may have been fully present at a time when the
decision to have only a "single"-account solution was made... but now
such constrained-consideration is in the distant past.

Honestly speaking... how many times have you have performed a
SAVE/RESTORE of an otherwise stand-alone ACCOUNT to a shadow/secondary
account -- and of all those instances... how often do you think (WAIT A
MINUTE... do i have any NAMED-COMMON's???)

Further... how many times have you gone to a customer site in a support
role and dropped to TCL, temporarily logged-to a second account only to
log-back-to the original?
(Again, how often do you think... while doing the logto... Gee, did any
of the account(s) incorporate a "NAMED COMMON"?)




...and so
you are left wondering why an application that has been working, all
the sudden has a certain file being stepped on with data that should be
in another file, or why data that you know to be on file is being
reported as missing, etc. When bizzare symptoms like this occur, it's
common to begin to suspect everything, including the environment.

I don't see how this behavior can be so surprising to people and how
something can suddenly break, etc. I don't think you're giving people
enough credit. Those who use named common know how it works, and
until now we haven't seen any great wailing about this.
(covered above)... it's not far-fetched... and all to common of a
potential scenario.

The doc seems
to be pretty clear and apps have been working for a decade with the
functionality as-is. Why all of a sudden are things going to suddenly
start breaking and causing support issues?
(ditto) in fact, you just fell into the trap!



...on NT, a FLASHBASIC program does not share the NAMED COMMON created by
that of a NON-FLASHED program... and conversely. IMO, this is a
laziness and an implementation oversight (documented or not). Sure,
someone at RD may have chased a path that a little performance gain
could be made through cutting functionality. Again, chase the
debugging exceptions on this! -- even if you have registered their
documentation note. :(

Non-flashed code is not compatible at all with flashed code. It's not
that one thing or another doesn't work between them, these are in
essence two completely different languages. Non-flashed code is
interpreted by PVA and flashed code is run and interpreted in C.
Flashed object comes in two pieces - the normal object code is
generated, and then those tokens are flashed into a completely
separate object area.
COMPATIBILITY... STOP... fortunately, little things like the "file
system" is a sacred cow and is still maintained in common between the
two implementations of BASIC... thank god! (well, actually... that is
even drifting these days... FSI vs. VME... absolute file pathing...
lack-of runtime checks on the number of called subroutines parameters
-- crashing otherwise in Flash...) -- however, to your point, it's poor
logic to consider the underlying implementation method used as being a
false justification for the supported logic in the upper layers.

but okay... down to earth and more to your point: assuming your
argument... if valid, how do you explain that the UNIX implementation
of flashbasic actually supports recognizing the global common for both
flashed and non-flashed versions? i will. i was responsible for
pick's flashbasic in the first place, and especially as initially
implemented on the Unix platforms -- and I can tell you that it is
solely a "design/implementation decision", and the decision was that we
would make it compatible... with all design considerations at hand. I
assure you that such a decision is not constrained by the fact that
pickbasic code is either interpreted/compiled -or- that the runtime is
embedded or via libraries, or that it is implemented in: native machine
code, native assembly, generic monitor code, virtual assembler, C, C++,
C#, Common Language Specification (CLS), .NET, java (or any combination
thereof).

The original intent was that Flashbasic and non-Flash code also would
have eventually come together in terms of any ability to CALL pickbasic
subroutines between flash/non-flashed code; but I relaxed this
constraint simply to get the original flashbasic release out.

However, due to the preceived crawl-walk-run adoption rate of
FLASHBASIC (and that certain large applications would be more
conservative in their adoption by flashing only critical portions of
their application) -- I didn't think it acceptable to allow potential
conflicts with NAMED COMMON being disjoint. Therefore, it was
implemented to work with both FLASH/non-FLASH environments -- even with
the modest overhead of dipping into virtual-mapped frames to
store/retrieve named-common variables and in marshalling their
contents.

The only valid argument here is that of compromised "priorities" --
however, one regularly has to question if these are being set wisely.
(Certainly, I can understand priorities; keep in mind that FLASH still
has only about 20% of the performance optimizations originally planned
for Flash -- however the initial performance results far exceeded our
expectations and proved to be sufficient enough not to have to look
back.)



When non-flashed code calls to a flashed program, only the non-flashed
object module gets executed. So your statement that the programs
don't share common is questionable because there's no such thing as
crossing from non-flash to flash anyway. The door is still open,
however, if you can verify that the non-flashed component of a flashed
object module is somehow incompatible with other non-flashed code. I
doubt this is the case however - the non-flashed part of a flashed
module is exactly the same as any other non-flashed object. Dump some
frames if you don't believe me.
Tony, hopefully the above answers some of this for you. You can always
share a resource, the question is -- will you? We did it on the Unix
platforms, it could have been done similarly on the NT -- it just
hasn't been.


And for reference, if you call from flashed code to non-flashed the
code will simply abort. The C runtime is trying to call to another C
routine that simply doesn't exist. (That's not a bug, it's equivalent
to using a CALL statement to execute a Proc.) If the flashed code is
started using its non-flashed object, then you get a PVA-PVA call and
everything should work fine.
<sigh>Trust me... interchangeable CALLING... was an implementation
short-cut only! I made the original decision to hold off on the
interfaces -- it wasn't supposed to stay that way! It's not a big
piece of work. We already had fluid interfaces between PVA and
C-runtimes... so this was of no issue.



...You can also
totally violate Pick's file security mechanism by opening a file in one
account, storing its filevariable in named common, and then LOGTO
another account and effectively have all permissions granted by the
previous account -- A feature/security hole?

I had to laugh at this one but I trust I just didn't understand it.
If someone has a password to login to one account, and a password to
login to another account, then how is it a security hole that they
have access to both sides?
especially on simply a password level, there's a difference between
partial access and carte blanche. let's assume you have a PAYROLL
account (tightly secure) and for which you only have partial privileges
(eg. those granted within the application). if the PAYROLL application
stored critical information in a named-common (eg. TONY'S SALARY INFO;
or opened a file-variable containing the SALARY INFO) and you could
somehow LOGTO another account that was less secure... one for which you
could utilize a variety of methods to get access to the NAMED-COMMON
space which followed you... then in our example, you just got access to
Tony's salary; or could, via the exposed file-pointer let you update
the salary info regardless of what the application in the PAYROLL
ACCOUNT might have otherwise controlled.

perhaps you might even be aware of the named-common initialization
logic in the PAYROLL account and could initialize your own version
BEFORE logging to the PAYROLL account.

hopefully you can extrapolate on the above...
You're also assuming that someone can
write, compile, and execute hazardous code in two different databases.
not necessarily. however, not all account-environments on a pick
machine are equal. I only need creative-access to the named-common
either BEFORE -or- AFTER visiting a potentially vulnerable ACCOUNT.

It's not a security violation when someone who has completely open
access into an environment actually uses the tools they have
available. The problem as described is access to resources, not the
resources themselves.
First, to leverage the above vulnerability doesn't take "completely
open access" into an environment... You might be surprised.

Basically an application that utilizes named-common application
potentially exposes critical resources to any account LOGGING TO or
FROM such an account. Therefore, a substantial TRUST-relationship is
implied here, and one that i'm not certain individuals writing
applications that incorporate named-common relate to.


As usual, if you have problems with the way security has been
implemented, contact your vendor. (I of course know you used to work
at PS, Dave.) On one hand I'll say; apparently this hasn't been an
issue for anyone since no one reports it.
who knew about the vulnerability? however, if no one reports such, do
they disappear?

On the other hand I'll say;
if you guys do have these issues and you don't report them then you
should be quite happy that you're getting from your vendor exactly
what you ask for. <RD&C> Old argument, just fun to see it come up
every couple days.
<groan>



After all, most named common initial setups have a flag to indicate
not-initialized, so all you'd have to do is set that flag.
Again, I would venture that M-A-N-Y of those "initialization flags" are
sensed using the "ASSIGNED()" function; second, there is regularly an
application assumption of isolation of data structures/programming
logic across PICK ACCOUNT-boundaries while maintaining common naming
conventions for their "Named Commons". Especially, in such predictable
scenarios, a mere initialization-flag would be useless without knowlege
of the LOGTO anomaly.

You make a very big assumption that applications don't have any
initialization code to recognize when a user first logs into an
account. This whole discussion is based on the view that developers
aren't reading docs and aren't coding properly when they do. With all
of the functional apps we have in this market I think that view isn't
lending credit where it's due.
if you use named common for an access report, do you necessarily
promote the subroutine's otherwise simplistic initialization logic to
second program at some LOGIN macro? most-likely not, whatta pain that
would be. talk about maintaining redundant data/programming
structures. the uses for named common are simply too vast to
pigeon-hole through common-initialization routines at LOGIN.

i admit that a brute force initialization at LOGIN would resolve a
"manually-executed" LOGTO vulnerability... but THEN what's the
advantage of named-common across account boundaries if such
re-initialization unconditionally occurs every login? (a fancy
cut-paste buffer?) also, if i did perform an 'execute logto'... there
then resides a tremendous recursively-delegatable TRUST factor with
where i'm going -- because no account-macro-initialization would be
automatically invoked upon completion of the execute. now a programmer
would have to code around that exposed point.


T

.

Relevant Pages

  • Re: flexible subroutine parameters
    ... >"common" module when it plainly is not a common module..if the outputs ... >CALL GETACCT using PARM1 PARM2 ... My goal with GETACCT is that I can pass it an account ... program doesn't have to care what "kind" of account it actually is. ...
    (comp.lang.cobol)
  • Re: so PayPAL is piece of mind for sellers ha ha
    ... Sorry to hear of your problems Paul, yes this is common. ... as a payment option on our websites. ... account for hundreds of times more online transactions than Paypal ...
    (uk.people.consumers.ebay)
  • Re: FSI Indices with translates the answer
    ... this would allow an application account to be attached ... relative to solely the common need you raised in this thread, ... WEBSITE1-account should be used to lookup the PRODUCTS-file. ... fact that a Basic program can perform an [EXECUTE "logto ...
    (comp.databases.pick)
  • Re: so PayPAL is piece of mind for sellers ha ha
    ... "We were recently notified that one of your buyers used an ... Sorry to hear of your problems Paul, yes this is common. ... account for hundreds of times more online transactions than Paypal ...
    (uk.people.consumers.ebay)
  • Re: SYSTEM(14) with D3
    ... if flashed and unflashed Named Common are accessible from one another. ... You flash or you don't. ... Expecting flash and non-flash to be ... While I knew there was some incompatibilities between FC and NFC, ...
    (comp.databases.pick)