RE: ODBC Security -- MIDRANGE-L

I love the idea of the logicals. I also appreciate everyone's input on this.
It makes sense to create these logicals, and perhaps segment them in a
separate library so that the ODBC connection only has to search one library
list. 

Thanks to all!

Patrick



> -----Original Message-----
> From: rob@dekko.com [SMTP:rob@dekko.com]
> Sent: Thursday, November 09, 2000 4:11 PM
> To:   MIDRANGE-L@midrange.com
> Subject:      RE: ODBC Security
> 
> 
> This is supposed to be part of V4R5.  Real field level security.  Before,
> under earlier releases, you did some things to the physical file so they
> could not read it directly but then only through a logical file.  And then
> the logical file would only select certain fields.  Do you need details?
> 
> 
> Rob Berendt
> 
> ==================
> Remember the Cole!
> 
> 
>  
> 
>                     "Shrader, Patrick"
> 
>                     <pshrader@wkep.com>        To:
> MIDRANGE-L@midrange.com                                           
>                     Sent by:                   cc:
> 
>                     owner-midrange-l@mi        Subject:     RE: ODBC
> Security                                            
>                     drange.com
> 
>  
> 
>  
> 
>                     11/09/00 02:01 PM
> 
>                     Please respond to
> 
>                     MIDRANGE-L
> 
>  
> 
>  
> 
> 
> 
> 
> 
> One ongoing question I have about this, and I am interested in
> suggestions,
> is how can you limit access to specific fields using ODBC. I hope it does
> not involve increasing my security level from 30.
> 
> I have an item master file that contains an item description and a cost.
> While I want some users to be able to access the basic item information, I
> don't want them to view costs. (This is a typical situation that can be
> applied to many files). Is there a way to limit visibility on specific
> fields in the file with ODBC?
> 
> As Rob said, green screens were much easier to secure -- but ODBC and
> Excel
> really makes some reports easy for the users.
> 
> Patrick Shrader
> 
> 
> 
> > -----Original Message-----
> > From:   rob@dekko.com [SMTP:rob@dekko.com]
> > Sent:   Thursday, November 09, 2000 1:15 PM
> > To:     MIDRANGE-L@midrange.com
> > Subject:     Re: ODBC Security
> >
> >
> > This message comes up on the list all the time.  Nice to see you're
> > concerned.
> >
> > Standard option is to have all files owned by a user who is NOT a group
> > profile.  Have *PUBLIC have no authority, or *EXCLUDE,  to any file.
> Then
> > change all of your 5250/batch/etc programs to use adopted authority of
> the
> > object owner.  I have an former coworker who had to implement this
> > solution
> > at his current place of employment.  Now comes the final question:  How
> do
> > you let the people who really use ODBC and who have a legitimate reason,
> > to
> > access these files?  After all we don't want to limit the 400 to green
> > screen only, do we?
> >
> > The solutions may be numerous.  I am kind of anxious to here those.
> >
> >
> > Rob Berendt
> >
> > ==================
> > Remember the Cole!
> >
> >
> >
> >
> >                     Quazy
> >
> >                     <quazy@SoftHome.net        To:
> > midrange-l@midrange.com
> >                     >                          cc:
> >
> >                     Sent by:                   Subject:     ODBC
> Security
> >
> >                     owner-midrange-l@mi
> >
> >                     drange.com
> >
> >
> >
> >
> >
> >                     11/09/00 12:25 PM
> >
> >                     Please respond to
> >
> >                     MIDRANGE-L
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > How does everyone deal with security on the 400 and the ability to use
> > ODBC?
> >
> > If production files are set to public authority to *change, what can I
> > do.  users don't have access to manipulate the data from the AS/400 (I
> > have
> > taken all those ways away).  But even if a user with basically no
> > authority
> > gets on through ODBC they could do anything they want to the database.
> >
> >
> > What is there you can do?
> >
> > +---
> > | This is the Midrange System Mailing List!
> > | To submit a new message, send your mail to MIDRANGE-L@midrange.com.
> > | To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
> > | To unsubscribe from this list send email to
> > MIDRANGE-L-UNSUB@midrange.com.
> > | Questions should be directed to the list owner/operator:
> > david@midrange.com
> > +---
> >
> >
> >
> > +---
> > | This is the Midrange System Mailing List!
> > | To submit a new message, send your mail to MIDRANGE-L@midrange.com.
> > | To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
> > | To unsubscribe from this list send email to
> > MIDRANGE-L-UNSUB@midrange.com.
> > | Questions should be directed to the list owner/operator:
> > david@midrange.com
> > +---
> +---
> | This is the Midrange System Mailing List!
> | To submit a new message, send your mail to MIDRANGE-L@midrange.com.
> | To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
> | To unsubscribe from this list send email to
> MIDRANGE-L-UNSUB@midrange.com.
> | Questions should be directed to the list owner/operator:
> david@midrange.com
> +---
> 
> 
> 
> +---
> | This is the Midrange System Mailing List!
> | To submit a new message, send your mail to MIDRANGE-L@midrange.com.
> | To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
> | To unsubscribe from this list send email to
> MIDRANGE-L-UNSUB@midrange.com.
> | Questions should be directed to the list owner/operator:
> david@midrange.com
> +---
+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to MIDRANGE-L@midrange.com.
| To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
| To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---