SYSTEM(14) with D3

#41

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]

Quote:

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.)

Quote:

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.)

Quote:

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???

Quote:

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.

Quote:

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"?)

Quote:

...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.

Quote:

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!

Quote:

...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.)

Quote:

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.

Quote:

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.

Quote:

...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...

Quote:

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.

Quote:

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.

Quote:

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?

Quote:

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

Quote:

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.

Quote:

T

#42

"dzigray" <google (AT) bridge2 (DOT) com> wrote

Quote:

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.

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.

Excuse me, but how is this a problem? If you have the permission to change,
compile and execute a progam in the secure PAYROLL account, it does not
matter if you then logto another account or not. You can do anything you
want with the Salary Info in the original account. If you have execute
privileges only, this situation should not arise.

And if you can't login to the PAYROLL account, you can't open the file...

In all the years I've used named Common, I just know when I have to re-init
Common and when not. It's pretty Basic. If you want to be able to do *>LOGTO
another.account (Ultimate or R83 debugger) and futz around, you're just
asking for trouble if you don't take Common into account. But you should
know that. Come to think of it this was forbidden.

Chandru

#43

Chandru Murthi wrote:

Quote:

"dzigray" <google (AT) bridge2 (DOT) com> wrote in message
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.

Excuse me, but how is this a problem? If you have the permission to change,
compile and execute a progam in the secure PAYROLL account, it does not
matter if you then logto another account or not.
in my above example, how do you get that one has (or requires) either

change/compile-permissions in the secure PAYROLL account in order to
exploit potential vulnerabilities?

Quote:

You can do anything you want with the Salary Info in the original account.
the vulnerability occurs outside the PAYROLL account -- that which is

exposed BEFORE logging into -or- AFTER logging out of the PAYROLL
account.

Quote:

If you have execute privileges only, this situation should not arise.
even if you have execute-only privileges in BOTH accounts, there are

various ways to exploit this with certain NAMED-COMMON scenarios.
perhaps simply by exploiting an incompatibility in named commons
between the two accounts, in a manner to allow an original named-common
to become invalid/corrupted so that when you returned to PAYROLL you
aborted and were able to drop to TCL. Of course, each potential
failure has other counter-attacks and so forth... but the original
vulnerability potential still stands.

Quote:

And if you can't login to the PAYROLL account, you can't open the file...

In all the years I've used named Common, I just know when I have to re-init
Common and when not. It's pretty Basic.
for sure, there's ways to minimize exposure here; but no matter what,

when you log to another account (and/or back again)... the potential
for exploitation exists -- it therefore becomes a trust scenario that
could be violated without total lock-down control of the entire system.

Quote:

If you want to be able to do *>LOGTO
another.account (Ultimate or R83 debugger) and futz around, you're just
asking for trouble if you don't take Common into account.
that's the point... but importantly far from being limited to a

debugger exploit.

Quote:

But you should know that. Come to think of it this was forbidden.
?

#44

"dzigray" <google (AT) bridge2 (DOT) com> wrote

Quote:

Chandru Murthi wrote:
"dzigray" <google (AT) bridge2 (DOT) com> wrote in message
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.

Excuse me, but how is this a problem? If you have the permission to
change,
compile and execute a progam in the secure PAYROLL account, it does not
matter if you then logto another account or not.
in my above example, how do you get that one has (or requires) either
change/compile-permissions in the secure PAYROLL account in order to
exploit potential vulnerabilities?

because if you did not have the ability to change/compile, how do you create
a program to do the logto?
re your other point, if you can recatalog a program with your own, you can
basically open up anything by, as you said, causing the mainline and its
common to crash.

Quote:

If you want to be able to do *>LOGTO
another.account (Ultimate or R83 debugger) and futz around, you're just
asking for trouble if you don't take Common into account.
that's the point... but importantly far from being limited to a
debugger exploit.

But you should know that. Come to think of it this was forbidden.
?
Oh not sure if LOGTO was allowed from BASIC debugger, or system debugger,

probably not, so you couldn't exploit the common var pass over.

#45

Chandru Murthi wrote:

Quote:

Excuse me, but how is this a problem? If you have the permission to
change,
compile and execute a progam in the secure PAYROLL account, it does not
matter if you then logto another account or not.
in my above example, how do you get that one has (or requires) either
change/compile-permissions in the secure PAYROLL account in order to
exploit potential vulnerabilities?

because if you did not have the ability to change/compile, how do you create
a program to do the logto?
chandru! you're not trying hard enough: (1) even though I don't have

such permissions in PAYROLL, suppose i have the ability to access a
MAINTENANCE account that does have such change/compile permissions?;
(2) perhaps there's even a built-in menu in MAINTENANCE that will LOGTO
the PAYROLL account for me, and returns when i'm done! (3) or perhaps I
have TCL access in MAINTENANCE and >logto PAYROLL directly! Maybe the
MAINTENANCE named-common is a different size than PAYROLL's so when I
go to PAYROLL via this mechanism, I end up ABORTING to the debugger...
(now I have TCL access at PAYROLL!) (yes, i know... there's
counter-attacks for each of these -- but it doesn't diminish the
existence of the exploit potential.)

Quote:

re your other point, if you can recatalog a program with your own, you can
basically open up anything by, as you said, causing the mainline and its
common to crash.
start there if it helps -- is that not a breach?

---
okay, better sample... no coding/compiling/cataloging necessary:

our hypothetical company is getting ready to roll-out a
NEW_PAYROLL_ACCOUNT and has its accounting and QA departments go in and
give it a final shakeout with totally bogus data while allowing various
PAYROLL application-level permissions.

Figuring all along (as you suggest) that there are NOT any real
SECURITY vulnerabilities in simply using a LOGTO... the company has a
general purpose LOGTO_MY_ACCOUNTS_program... and its been working great
for years!

Then for today's QA testing of the NEW_PAYROLL_ACCOUNT, first i...
(actually, it's nearing Christmas, so first i want to check on my
actual vacation time, so I instead logto the real production PAYROLL
account and check my vacation time. <<behind the scenes: RUN
init_named_common>>; great! i get friday off! then i use the above
LOGTO_MY_ACCOUNTS_program to logto the NEW_PAYROLL_ACCOUNT for testing
<<behind the scenes: RUN init_named_comm.... oops, no need! -- already
initialized!>>; I now list the testing account's PAYROLL for current
month -- HOLY SMOKES! R-E-A-L PAYROLL DATA!!! I FALL OUT OF MY CHAIR!
Wait...Chandru makes..HOW MUCH!??? NO WAY!!! NOBODY'S WORTH THAT
MUCH!!! I'M NOW REALLY DISGRUNTLED... ENTIRE SALARY LIST IS
SURPRISINGLY POSTED ON COMPANY INTRANET... GREAT NEWS TRAVELS FAST!
half of company is now disgruntled and resign (not just those having
issues with Chandru's salary; in fact, VP1 could not believe VP2 made
so much!); in parallel several heads roll in the technology department
for this bug (er, feature??.) Now even more people are disgruntled..
company cannot service its accounts; mega disaster! Company forced to
shutdown! Chandru's stock options are now worthless!

That "NAMED COMMON"! -- real power for real programmers!
LOL!

#46

dzigray wrote:

Quote:

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.

I don't have time at present to respond to all your points, but may I
say how very enjoyable it has been to follow your posts? You exhibit a
clarity of thought that is not at all common, and your recollections
from your days at Pick Systems seem equally clear.

In the matter of named common, we are in complete agreement. It is a
behaviour which has the potential to cause serious harm, and should
therefore be addressed, even if that means retiring some "functionality"
for those who've come to rely in this little peccadillo. Or at the very
least, so kind of switch or option should be put in place to select the
correct behaviour.

As for EXECUTE 'LOGTO <account>':@AM:COMMAND, I say yuck, Yuck, YUCK and
Pfooie! Sure, it might work today, and even tomorrow, but man what a
kludge! And will it work next week, after an upgrade? Or if the client
changes to a different platform? I don't like it. Not a bit.

Cheers,
Luke

#47

Goo'day, Luke,

On Thu, 31 Aug 2006 00:08:08 GMT, Luke Webber <luke (AT) webber (DOT) com.au>
wrote:

Quote:

dzigray wrote:
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.

I don't have time at present to respond to all your points, but may I
say how very enjoyable it has been to follow your posts? You exhibit a
clarity of thought that is not at all common, and your recollections
from your days at Pick Systems seem equally clear.

In the matter of named common, we are in complete agreement.
snip

Mate, this reads like your next move will be to try to borrow money
from him.... <grin>

<Butter><Butter>
Regards,

Bruce Nichol
Talon Computer Services
ALBURY NSW Australia

http://www.taloncs.com.au

If it ain't broke, fix it until it is....

#48

Luke Webber wrote:

Quote:

dzigray wrote:
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.

I don't have time at present to respond to all your points, but may I
say how very enjoyable it has been to follow your posts? You exhibit a
clarity of thought that is not at all common, and your recollections
from your days at Pick Systems seem equally clear.

In the matter of named common, we are in complete agreement. It is a
behaviour which has the potential to cause serious harm, and should
therefore be addressed, even if that means retiring some "functionality"
for those who've come to rely in this little peccadillo. Or at the very
least, so kind of switch or option should be put in place to select the
correct behaviour.

As for EXECUTE 'LOGTO <account>':@AM:COMMAND, I say yuck, Yuck, YUCK and
Pfooie! Sure, it might work today, and even tomorrow, but man what a
kludge! And will it work next week, after an upgrade? Or if the client
changes to a different platform? I don't like it. Not a bit.

Cheers,
Luke

I thought it was complete rubbish.

#49

Chandru:

I believe UV allows creating a file in another account. I think (bad idea
sometimes) I read about this in the U2 mail list.

Bill

"Chandru Murthi" <cmur_xyz_thi (AT) xyz_seeinggree_xyz_n (DOT) net> wrote

Quote:

Move and Steal file are D3 specific. I am on UV at the moment. While in
theory you can Create-file and use Unix commands to move the fiels, that
is inadvisable. So I prefer Logto to the account I am doing most of the
work in.

Chandru
"Peter McMurray" <excalibur21 (AT) bigpond (DOT) com> wrote in message
news:rlvIg.19104$rP1.1357 (AT) news-server (DOT) bigpond.net.au...
Hi Mark & Grigory
You are both terrifying me moving things around like this when I throw in
STEAL-FILE I wonder what else I have to lock out for security. I have
got a pseudo TCL built into my system that limits what users can do but
it has not been used much. Given the differences that we have uncovered
between VME and FSI I think I will do some more testing. I always used
to use the Pick access control in the Account MDS item I must get back to
doing that I feel.
Thanks for the tips
Peter McMurray
By the way has anyone come up with an answer to the original query on
this thread - loading SYSTEM(14) - if they have I have missed it.
"GVP" <gvp (AT) infotools (DOT) ru> wrote in message
news:1156738882.781531.113860 (AT) m73g2000cwd (DOT) googlegroups.com...
Hello Peter,

MOVE-FILE is very powerful. For example I using MOVE-FILE for rename an
account in ADM.PRG.
Also You can use create-file with (r option

regards,

#50

"dzigray" wrote:

Quote:

Some final footnotes, below... (after that, i think i'm COMMONed out);

hear hear - after going through this entire post though, it seems
we're more in agreement. Uh oh!

Quote:

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.)

Sigh, no, but I see your reasoning. I meant I expect named common to
be "intact", that is, "as it was when I left the account I jumped to"
compared to "as it was when I originally made the jump". It's all one
environment. Regardless of where I am, if I change a variable I
expect it to remain changed in my environment.

Quote:

Trust me... I totally get how to take advantage of this..

No doubt.

Quote:

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.

Agreed, pushing and popping a stack is a system function. This is
exactly how plain Common works. If you don't want to preserve your
BASIC workspace to persist across a Logto, and you don't want your
environment to survive termination of the BASIC runtime, then use
plain Common. If you do want these features, use Named Common.

I think named common would be overly complicated if someone did "fix"
it so that variables are selectively available in different contexts.
Reference this code:
common /abc/ f.custs
open "custs" f.custs else stop
data "do.something" ; * ack to Dave's note on this
execute "logto elsewhere"
When I get to account "elsewhere", what is the value of f.custs?
Assigned or no? Is it dependent on the ret/upd values for my user,
the accounts, and the files? What happens if I do this?:
open "data.acct,custs," to f.custs else stop
It's perfectly valid to want to continue to operate on the custs file
in the data.acct regardless of whether I'm logged to my home account
or temporarily in the "elsewhere" account.

I agree that there could be security contexts where access to/from
various accounts is not allowed, and this construct could circumvent
that. But now we have a choice for who we're going to tick off first,
the programmer that can't do what he's being asked to do, or the
sysadmin who's upset that the programmer can do stuff that maybe he
shouldn't. Personally I think the inability to do a technical
function is a technical problem, and it's a personnel problem when a
programmer intentionally or accidentally violates security. I don't
want my technical features removed because someone else considers it
to be their potential security risk. And for what it's worth, the
number of Pick sites that are hardened with upd/ret access is vastly
smaller than the number of sites that make use of named common. If
it's a game of numbers I think the current functionality wins out.

Quote:

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???

Didn't know that, I'd call that a bug. Please don't go overboard
Dave. The Abort statement is documented to do a full stop, not
Return. This is different than named common which does behave as
documented. If this Abort issue is important, someone will probably
report it. If not then maybe people do prefer the current behavior.

Quote:

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.

My point was that the behavior is exactly as it's documented. Feel
free to disagree with how you feel it should work, I'll respect and
acknowledge your opinion and we can debate the merits of a proposed
alternative. What I'm focusing on here is whether this is a "bug" or
not. The execution of the software is consistent with the
documentation. Like it or not, that can't be considered a bug. I
don't know how much more clear this can be.

Quote:

Suppose you have a completely stand-alone production ACCOUNT that you
ultimately save/restore into some backup account...[snip]

I consider this whole snipped section invalid as the same can be said
for hardcoded paths in code and catalog items, q-pointers that still
lead to production accounts, and many other anomalies which can occur
from changing account names in a production environment.

Quote:

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.)

That quote makes this thread worthwhile for me. You've accurately
described the exact situation that I think RD still faces even now.
The product has to get out even with some engineering challenges
unresolved. Yes, there are some FSI/VME and NT/*nix differences that
still need to be addressed. It's not perfect but the product responds
to the needs of the majority of its users, and in general they aren't
complaining. As always, no excuses or justification or any other
approval or disapproval implied on my part - I'm just saying those are
the dynamics at work and nothing has changed in this regard since you
left 11-12 years ago.

Quote:

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.

I defer to your knowledge in this area, I was never involved in the
code or engineering decisions. Sometimes decisions are made because
we don't have immediate answers which allow us to go to market with a
stable platform. It's better to go production without a couple
features than it is to go with something that's likely to break.
(You're well aware of this Dave and essentially said so yourself
above.) However, sometimes these challenges turn out to be even
bigger than we thought. I can only guess that the differences between
Flash and Non-Flash have been too big to justify the effort required
to completely resolve them for all platforms. That implies business
as well as technical decisions have had an influence.

Quote:

how is it a security hole ...?

hopefully you can extrapolate on the above...

Given your scenario I now agree that there is potential for abuse -
thanks for that. Accomplishing this requires someone with motive,
skills, knowledge of the code, and an environment with lots of holes
in the application : not doing inits, allowing logto without logoff,
access to TCL and the compiler, and many more issues. Based on my
experience I don't think the stars will have this precise alignment in
our lifetimes. What's more likely is that this discussion could
prompt requests for consulting engagements for security audits just in
case some IT manager is feeling a little "insecure" (pun intended).
If I get any calls on this, I'll refer them to you Dave.

I now have a much better view of why you call this a bug. It's the
sort of thing that Microsoft would issue a patch for and then people
would scream for months that their systems no longer worked. RD can't
afford that.

Quote:

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.

That's something I've had in mind from the start. When you do a logto
from BASIC and you expect to come back, you may be jumping to an
application screen where you expect the user will perform
application-related activities before coming back through normal
menus. Or, or you will login to a q-pointer (with password) which
allows you commandline access to run some custom function (that
"do.something" example I used) before you come back. For this
vulnerability to be exploited, you need a secure account which
releases a user into a highly insecure area, like logging from Payroll
to Games, where the Games menu has an exit to TCL. It seems to me all
of these problems can be managed with developer education rather than
locking down the environment.

Now we're at the point where we need to measure degrees of buggyness
(is that like "truthiness"?) required for a change of defined
functionality. Hands down, I think the answer is that this isn't
significant enough for RD to take a chance on breaking existing
functionality for a multitude of their users. (That's just me though,
for better or worse I have no influence over there.) If some large
company felt this was worth a change then RD may be able to provide a
system-level option which would allow for further restriction of named
common - but it would have to be off by default. Such changes are
made with a business decision, not technical, and would need to be
justified as such. Have I ever mentioned addressing bugs with one's
vendor as a business matter rather than reporting them in forums or
even with a Support desk?

Good discussion, thanks.
T