Suprtool clearly abides by Image Security at DBOPEN time, but what about
when gathering data? Since its claim to fame is speed, achieved by
bypassing Image almost entirely via MR NOBUF, it would likely have a bit of
trouble skipping over Image items your particular password isn't supposed to
see.
The password changes you describe prevented your users from DBOPENing your
base.
Tracy Pierce
> -----Original Message-----
> From: Art Bahrs [mailto:[log in to unmask]]
> Sent: Wednesday, November 24, 2004 8:35 AM
> To: [log in to unmask]
> Subject: Re: Using the "@" list in TurboIMAGE
>
>
> Hi Tracy :)
> I agree wholeheartedly with being lazy it is better :)
>
> I believe that SuprTool does actually follow the Image
> security ...
> IIRC when I changed the database schema to have new passwords
> and rebuilt
> the SRN databases away from the generic standard passwords
> that SRN used a
> bunch of things written for people stopped working right...
> because they
> used the 'readonly' passwords that I had changed... But the
> jobs that used
> the ';' and were logged on as the database creator and such
> continued to
> work...
>
> So, the moral probably is to write all jobs and command
> files and such
> to use only the necessary levels of passwords and not the God
> passwords :)
>
> Art "thinking about it all over again... :) " Bahrs
>
> =======================================================
> Art Bahrs, CISSP Information Security The
> Regence Group
> (503) 553-1425 FAX (503) 553-1453
>
>
> |---------+-------------------------------->
> | | "Tracy Pierce" |
> | | <[log in to unmask]
> | | rg> |
> | | Sent by: "HP-3000 |
> | | Systems Discussion" |
> | | <[log in to unmask]
> | | DU> |
> | | |
> | | |
> | | 11/24/2004 07:56 AM |
> | | Please respond to |
> | | "Tracy Pierce" |
> | | |
> | | |-------------------||
> | | | [ ] Secure E-mail ||
> | | |-------------------||
> |---------+-------------------------------->
>
> >-------------------------------------------------------------
> -------------------------------------------------------------|
> |
> |
> | To: [log in to unmask]
> |
> | cc:
> |
> | Subject: Re: [HP3000-L] Using the "@" list in
> TurboIMAGE |
>
> >-------------------------------------------------------------
> -------------------------------------------------------------|
>
>
>
>
> Of Course you want to use copylibs!
>
> The laziness factor I mention is manifested in those copylib buffers
> though:
> in every shop I've ever worked, the copylib buffers
> correspond to the @
> ImageItemList. The simplicity of that method lets you
> largely ignore the
> lovely security tools built into Image.
>
> I always wanted to try, in cases such as HR or Payroll
> databases, having
> separate copylib'd buffers and ImageItemLists for various
> Image usernames,
> which would let you assign semi-sensitive programming
> projects to people
> who
> have no business seeing particular data items, as long as you
> protected the
> schema and its passwords.
>
> I'm not sure what Suprtool's Edit would do with this; I'd be
> willing to bet
> that Mr Greer had the good sense to respect Image security.
> But Suprtool
> itself would probably choke - it really wants to ignore
> security details in
> exchange for speed.
>
> Tracy mixed emotions Pierce
>
>
> > -----Original Message-----
> > From: [log in to unmask] [mailto:[log in to unmask]]
> > Sent: Tuesday, November 23, 2004 3:57 PM
> > To: Tracy Pierce
> > Cc: [log in to unmask]
> > Subject: Re: [HP3000-L] Using the "@" list in TurboIMAGE
> >
> >
> >
> >
> >
> >
> > Hi Tracy and All :)
> > Actually, I was taught from day one to always put your
> > record layouts
> > in CopyLibs as it made updating and recompiling much easier
> and clean.
> > Also, you didn't go "I didn't think that program used that
> > file?" near as
> > much when you modify a file's record structure.
> >
> > Art "Remembering some of the tricks still" Bahrs
> >
> > =======================================================
> > Art Bahrs, CISSP Information Security The
> > Regence Group
> > (503) 553-1425 FAX (503) 553-1453
> >
> >
> > |---------+-------------------------------->
> > | | "Tracy Pierce" |
> > | | <[log in to unmask]
> > | | rg> |
> > | | Sent by: "HP-3000 |
> > | | Systems Discussion" |
> > | | <[log in to unmask]
> > | | DU> |
> > | | |
> > | | |
> > | | 11/23/2004 03:55 PM |
> > | | Please respond to |
> > | | "Tracy Pierce" |
> > | | |
> > | | |-------------------||
> > | | | [ ] Secure E-mail ||
> > | | |-------------------||
> > |---------+-------------------------------->
> >
> > >-------------------------------------------------------------
> > -------------------------------------------------------------|
> > |
> > |
> > | To: [log in to unmask]
> > |
> > | cc:
> > |
> > | Subject: Re: [HP3000-L] Using the "@" list in
> > TurboIMAGE |
> >
> > >-------------------------------------------------------------
> > -------------------------------------------------------------|
> >
> >
> >
> >
> > I think your way's correct, and I think the @ list was
> > generally used as a
> > lazy man's solution, worked around via compile-everything.
> >
> > There's no reason you can't put a specific item list in a copylib.
> >
> > Tracy (lazy as anybody) Pierce
> >
> > > -----Original Message-----
> > > From: Adriana & Timothy Atwood [mailto:[log in to unmask]]
> > > Sent: Tuesday, November 23, 2004 1:54 PM
> > > To: [log in to unmask]
> > > Subject: Re: Using the "@" list in TurboIMAGE
> > >
> > >
> > > Nope, I never use "@". Everything at every shop were I had
> > > any say over the
> > > standards was done exactly as you describe. First an explicit
> > > list then use
> > > the "*" for current list.
> > >
> > > Works too. One of the systems I am currently looking after
> > > has over 400
> > > Cobol programs. I change databases to fulfill new
> > > requirements all the time.
> > > Never have to waste time recompiling hundreds of programs.
> > >
> > > As far as I am concerned, there is never any good reason to
> > > use "@". List
> > > processing overhead? If done as described so the lists are
> > > only processed
> > > once, I have never noticed any significant impact in list
> > processing.
> > >
> > > ----- Original Message -----
> > > From: "Walter Murray" <[log in to unmask]>
> > > To: <[log in to unmask]>
> > > Sent: Monday, November 22, 2004 9:17 PM
> > > Subject: [HP3000-L] Using the "@" list in TurboIMAGE
> > >
> > >
> > > > [My apologies if this is a duplicate for some readers. I
> > > had trouble last
> > > > week with some of my postings not making the jump through
> > > the gateway to
> > > > 3000-L.]
> > > >
> > > > When I learned IMAGE yea many years ago, I got the notion
> > > that the right
> > > way
> > > > to call DBGET and related procedures was with an explicit
> > > list parameter
> > > > specifying the particular items of interest. If I was
> > > concerned with the
> > > > overhead of processing such a list, I could establish a
> > > "current list",
> > > > typically by doing a directed read to record 0 (which I
> > > knew would return
> > > > condition 12) and using "*;" in subsequent calls. The
> > > theory was that, if
> > > > there were structural changes to the database, such as new
> > > items added to
> > > > the dataset, it would not be necessary to change and
> recompile any
> > > programs
> > > > that did not use the new items.
> > > >
> > > > In practice, however, it seems as though everybody just
> > > uses "@;" all the
> > > > time. The buffer layout gets put into a COPY library. If
> > > items are added
> > > > or modified, you have to track down every program that uses
> > > that dataset
> > > > and, at a minimum, recompile it. If you miss one,
> > mysterious things
> > > happen,
> > > > as when the program's buffer becomes too short for the
> > > newly enlarged
> > > > dataset layout.
> > > >
> > > > Am I correct in my belief, based on admittedly limited
> > > observation, that
> > > > practically everybody always uses an "@;" list? If so, is
> > > there any good
> > > > reason for this? Is "@;" faster than "*;"? If so, why?
> > > And is it enough
> > > > faster to justify the risk and inconvenience of having to
> > > recompile many
> > > > programs whenever a minor structural database change is
> > > made? Or am I
> > > > missing something more significant?
> > > >
> > > > Thanks.
> > > >
> > > > Walter
> > > >
> > > >
> > > >
> > > >
> > > > ----== Posted via Newsfeeds.Com -
> > Unlimited-Uncensored-Secure Usenet
> > > News==----
> > > > http://www.newsfeeds.com The #1 Newsgroup Service in the
> > > World! >100,000
> > > Newsgroups
> > > > ---= East/West-Coast Server Farms - Total Privacy via
> > > Encryption =---
> > > >
> > > > * To join/leave the list, search archives, change list
> settings, *
> > > > * etc., please visit
> http://raven.utc.edu/archives/hp3000-l.html *
> > >
> > > * To join/leave the list, search archives, change list settings, *
> > > * etc., please visit http://raven.utc.edu/archives/hp3000-l.html *
> > >
> >
> > * To join/leave the list, search archives, change list settings, *
> > * etc., please visit http://raven.utc.edu/archives/hp3000-l.html *
> >
> >
> >
> >
> >
> > ==============================================================
> > ================
> > IMPORTANT NOTICE: This communication, including any
> > attachment, contains information that may be confidential or
> > privileged, and is intended solely for the entity or
> > individual to whom it is addressed. If you are not the
> > intended recipient, you should delete this message and are
> > hereby notified that any disclosure, copying, or distribution
> > of this message is strictly prohibited. Nothing in this
> > email, including any attachment, is intended to be a legally
> > binding signature.
> > ==============================================================
> > ================
> >
>
> * To join/leave the list, search archives, change list settings, *
> * etc., please visit http://raven.utc.edu/archives/hp3000-l.html *
>
>
>
>
>
> ==============================================================
> ================
> IMPORTANT NOTICE: This communication, including any
> attachment, contains information that may be confidential or
> privileged, and is intended solely for the entity or
> individual to whom it is addressed. If you are not the
> intended recipient, you should delete this message and are
> hereby notified that any disclosure, copying, or distribution
> of this message is strictly prohibited. Nothing in this
> email, including any attachment, is intended to be a legally
> binding signature.
> ==============================================================
> ================
>
> * To join/leave the list, search archives, change list settings, *
> * etc., please visit http://raven.utc.edu/archives/hp3000-l.html *
>
* To join/leave the list, search archives, change list settings, *
* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *
|
