"PUBLIC" group in DB2 - a close look into it

ED

"PUBLIC" group in DB2 - a close look into it
Hi DB2-Lers,

DB2 v7 for OS/390 with ACF2.

My question may look a trivial one, but I need a close look at it.
The "PUBLIC" group known in DB2 which covers all local users in a DB2 server.
I have some questions about it:

- Does "PUBLIC" mean everybody from anywhere? or only those user-IDs defined by the security system (in our case is ACF2)?
- If ACF2 doesn't permit a user's access, can we guarantee that this user cannot access any DB2 "PUBLIC" tables?
- Assuming "PUBLIC" as a group, can we change/define the users which belong to this group?

What I need is a deeper look inside the special DB2 group called "PUBLIC", in case you know any reference to help me, please let me know.

Why "PUBLIC" is a concern to me?
Shortly we will be opening our network to the Internet, so Internet users will access Web applications which access DB2 on the mainframe. We need to make sure that no Internet hacker can access our DB2 through the "PUBLIC" group.

Any help appreciated. Thanks...

---------------------------------------------------------------------------------
Welcome to the IDUG DB2-L list. To unsubscribe, go to the archives and home page at http://www.idugdb2-l.org/archives/db2-l.html. From that page select "Join or Leave the list". If you will be out of the office, send the SET DB2-L NO MAIL command to [login to unmask email] The IDUG List Admins can be reached at [login to unmask email] Find out the latest on IDUG conferences at http://conferences.idug.org/index.cfm

Steve Whittaker

Re: "PUBLIC" group in DB2 - a close look into it
(in response to ED)
Just my humble opion; when granting the authority to PUBLIC I regard that as meaning that 'anyone' that has a valid TSO account and can get to the DB2 resources will be able to access any table that is open to PUBLIC.
Based on what type of access has been granted to public, ie; select, insert, update, delete, that will determine what they can do.
We have 1000's of clients coming into the DB2 objects via DB2 Connect and the web and the way we control this is with our IBMgroups (top secret in our case). We do NOT open up tables in production to PUBLIC; that is a big no-no in our shop.
We have specific IBMgroups set up that allow select authority to specific tables etc.
You cannot, to my knowledge, make any changes to the PUBLIC group.

HTH:
--Steve....

-----Original Message-----
From: DANISH, EMAD [mailto:[login to unmask email]
Sent: Wednesday, December 03, 2003 6:11 AM
To: [login to unmask email]
Subject: "PUBLIC" group in DB2 - a close look into it


Hi DB2-Lers,

DB2 v7 for OS/390 with ACF2.

My question may look a trivial one, but I need a close look at it.
The "PUBLIC" group known in DB2 which covers all local users in a DB2 server.
I have some questions about it:

- Does "PUBLIC" mean everybody from anywhere? or only those user-IDs defined by the security system (in our case is ACF2)?

- If ACF2 doesn't permit a user's access, can we guarantee that this user cannot access any DB2 "PUBLIC" tables?
- Assuming "PUBLIC" as a group, can we change/define the users which belong to this group?

What I need is a deeper look inside the special DB2 group called "PUBLIC", in case you know any reference to help me, please let me know.

Why "PUBLIC" is a concern to me?
Shortly we will be opening our network to the Internet, so Internet users will access Web applications which access DB2 on the mainframe. We need to make sure that no Internet hacker can access our DB2 through the "PUBLIC" group.

Any help appreciated. Thanks...

--------------------------------------------------------------------------------- Welcome to the IDUG DB2-L list. To unsubscribe, go to the archives and home page at http://www.idugdb2-l.org/archives/db2-l.html. From that page select "Join or Leave the list". If you will be out of the office, send the SET DB2-L NO MAIL command to [login to unmask email] The IDUG List Admins can be reached at [login to unmask email] Find out the latest on IDUG conferences at http://conferences.idug.org/index.cfm

---------------------------------------------------------------------------------
Welcome to the IDUG DB2-L list. To unsubscribe, go to the archives and home page at http://www.idugdb2-l.org/archives/db2-l.html. From that page select "Join or Leave the list". If you will be out of the office, send the SET DB2-L NO MAIL command to [login to unmask email] The IDUG List Admins can be reached at [login to unmask email] Find out the latest on IDUG conferences at http://conferences.idug.org/index.cfm

Georg Peter

AW: "PUBLIC" group in DB2 - a close look into it
(in response to Steve Whittaker)
Emad,

simply allowing "blanket access" to certain DB2 objects is usually an unwise
choice. Objects granted PUBLIC can be accessed by hackers or folks who "bend
the rules"........

With kind regards - mit freundlichen Gruessen,
Georg H. Peter c/o
-------------------------------------------------------------------
Datenzentrale Baden-Wuerttemberg
Software Development & Technology Center
Knowledge Center Database Systems
Krailenshaldenstrasse 44, 70469 Stuttgart, Germany, Europe
e:mail [login to unmask email]
Phone 0049-711-8108-271
PC-Fax 004971189696071
Internet (only in german language):http://www.dzbw.de < http://www.dzbw.de/ >
----------------------------------------------------------------------
»We don't make mistakes - only happy accidents.«


-----Ursprüngliche Nachricht-----
Von: DANISH, EMAD [mailto:[login to unmask email]
Gesendet: Mittwoch, 3. Dezember 2003 12:11
An: [login to unmask email]
Betreff: "PUBLIC" group in DB2 - a close look into it


Hi DB2-Lers,

DB2 v7 for OS/390 with ACF2.

My question may look a trivial one, but I need a close look at it.
The "PUBLIC" group known in DB2 which covers all local users in a DB2
server.
I have some questions about it:

- Does "PUBLIC" mean everybody from anywhere? or only those user-IDs defined
by the security system (in our case is ACF2)?

- If ACF2 doesn't permit a user's access, can we guarantee that this user
cannot access any DB2 "PUBLIC" tables?
- Assuming "PUBLIC" as a group, can we change/define the users which belong
to this group?

What I need is a deeper look inside the special DB2 group called "PUBLIC",
in case you know any reference to help me, please let me know.

Why "PUBLIC" is a concern to me?
Shortly we will be opening our network to the Internet, so Internet users
will access Web applications which access DB2 on the mainframe. We need to
make sure that no Internet hacker can access our DB2 through the "PUBLIC"
group.

Any help appreciated. Thanks...

----------------------------------------------------------------------------
----- Welcome to the IDUG DB2-L list. To unsubscribe, go to the archives and
home page at http://www.idugdb2-l.org/archives/db2-l.html. From that page
select "Join or Leave the list". If you will be out of the office, send the
SET DB2-L NO MAIL command to [login to unmask email] The IDUG List
Admins can be reached at [login to unmask email] Find out the
latest on IDUG conferences at http://conferences.idug.org/index.cfm


---------------------------------------------------------------------------------
Welcome to the IDUG DB2-L list. To unsubscribe, go to the archives and home page at http://www.idugdb2-l.org/archives/db2-l.html. From that page select "Join or Leave the list". If you will be out of the office, send the SET DB2-L NO MAIL command to [login to unmask email] The IDUG List Admins can be reached at [login to unmask email] Find out the latest on IDUG conferences at http://conferences.idug.org/index.cfm

Colin Clayton

Re: "PUBLIC" group in DB2 - a close look into it
(in response to Georg Peter)


Emad,

as you say, its not a trivial question and I don't want to sound as if I am
fobbing you off with the RTFM answer, however... I'd suggest you read Part 3
of the DB2 Admin Guide. The quoted text is copied from there.

"You can grant privileges to the ID PUBLIC, making them available to all IDs
at the local DB2." - The responsibility is with you, as the security
administrator, to ensure that any access to DB2 is controlled by your
security software - RACF / ACF2 etc.

"Whether or not a process can gain access to a specific DB2 subsystem can be
controlled outside of DB2. A common procedure is to grant access only
through
RACF or some similar security system. Profiles for access to DB2 from
various environments, and DB2 address spaces, are defined as resources to
RACF. Each
request to access DB2 is associated with an ID. RACF checks that the ID is
authorized for DB2 resources and permits, or does not permit, access to
DB2."

I'd also be surprised if any of your sensitive data is open to PUBLIC
access. In most sites I have seen, PUBLIC is only ever used on development
or test subsystems. In production environments access is granted to specific
RACF secondary authids and usually only allows access to the data via an
application program since you do not want anyone running 'ad hoc' updates to
the data.

You should also read Chapter 18 "Controlling inbound connections that use
TCP/IP protocols".

Colin




---------------------------------------------------------------------------------
Welcome to the IDUG DB2-L list. To unsubscribe, go to the archives and home page at http://www.idugdb2-l.org/archives/db2-l.html. From that page select "Join or Leave the list". If you will be out of the office, send the SET DB2-L NO MAIL command to [login to unmask email] The IDUG List Admins can be reached at [login to unmask email] Find out the latest on IDUG conferences at http://conferences.idug.org/index.cfm

Mike Holmans

Re: "PUBLIC" group in DB2 - a close look into it
(in response to Colin Clayton)
PUBLIC isn't a group in any meaningful sense. Something granted to PUBLIC is available to anyone.

Mike Holmans
Database consultant
BTexact ESS Database Services
[login to unmask email]
__________________________________________
British Telecommunications plc
Registered office: 81 Newgate Street London EC1A 7AJ
Registered in England no. 1800000
This electronic message contains information from British Telecommunications plc which may be privileged and confidential. The information is intended to be for the use of the individual(s) or entity named above. If you are not the intended recipient, be aware that any disclosure, copying, distribution or use of the contents of this information is prohibited. If you have received this electronic message in error, please notify us by telephone or email (to the number or address above) immediately.

Activity and use of the British Telecommunications plc email system is monitored to secure its effective operation and for other lawful business purposes. Communications using this system will also be monitored and may be recorded to secure effective operation and for other lawful business purposes.

-----Original Message-----
From: DB2 Data Base Discussion List [mailto:[login to unmask email]On Behalf Of DANISH, EMAD
Sent: 03 December 2003 11:11
To: [login to unmask email]
Subject: "PUBLIC" group in DB2 - a close look into it


Hi DB2-Lers,

DB2 v7 for OS/390 with ACF2.

My question may look a trivial one, but I need a close look at it.
The "PUBLIC" group known in DB2 which covers all local users in a DB2 server.
I have some questions about it:

- Does "PUBLIC" mean everybody from anywhere? or only those user-IDs defined by the security system (in our case is ACF2)?

- If ACF2 doesn't permit a user's access, can we guarantee that this user cannot access any DB2 "PUBLIC" tables?
- Assuming "PUBLIC" as a group, can we change/define the users which belong to this group?

What I need is a deeper look inside the special DB2 group called "PUBLIC", in case you know any reference to help me, please let me know.

Why "PUBLIC" is a concern to me?
Shortly we will be opening our network to the Internet, so Internet users will access Web applications which access DB2 on the mainframe. We need to make sure that no Internet hacker can access our DB2 through the "PUBLIC" group.

Any help appreciated. Thanks...

--------------------------------------------------------------------------------- Welcome to the IDUG DB2-L list. To unsubscribe, go to the archives and home page at http://www.idugdb2-l.org/archives/db2-l.html. From that page select "Join or Leave the list". If you will be out of the office, send the SET DB2-L NO MAIL command to [login to unmask email] The IDUG List Admins can be reached at [login to unmask email] Find out the latest on IDUG conferences at http://conferences.idug.org/index.cfm


---------------------------------------------------------------------------------
Welcome to the IDUG DB2-L list. To unsubscribe, go to the archives and home page at http://www.idugdb2-l.org/archives/db2-l.html. From that page select "Join or Leave the list". If you will be out of the office, send the SET DB2-L NO MAIL command to [login to unmask email] The IDUG List Admins can be reached at [login to unmask email] Find out the latest on IDUG conferences at http://conferences.idug.org/index.cfm

Georg Peter

AW: "PUBLIC" group in DB2 - a close look into it
(in response to Mike Holmans)
Mike,

you are absolutely right. But I've found one case where we did a PUBLIC
grant:

We granted the BINDADD privilege to PUBLIC in our test environments to allow
all our DB2 programmers to create DB2 application plans and packages....

With kind regards - mit freundlichen Gruessen,
Georg H. Peter c/o
-------------------------------------------------------------------
Datenzentrale Baden-Wuerttemberg
Software Development & Technology Center
Knowledge Center Database Systems
Krailenshaldenstrasse 44, 70469 Stuttgart, Germany, €urope
e:mail [login to unmask email]
Phone 0049-711-8108-271
PC-Fax 004971189696071
Internet (only in german language): < http://www.dzbw.de/ > http://www.dzbw.de
----------------------------------------------------------------------
»We don’t make mistakes – only happy accidents.«


-----Ursprüngliche Nachricht-----
Von: [login to unmask email] [mailto:[login to unmask email]
Gesendet: Mittwoch, 3. Dezember 2003 13:14
An: [login to unmask email]
Betreff: Re: "PUBLIC" group in DB2 - a close look into it


PUBLIC isn't a group in any meaningful sense. Something granted to PUBLIC is
available to anyone.

Mike Holmans
Database consultant
BTexact ESS Database Services
[login to unmask email] <mailto:[login to unmask email]>


---------------------------------------------------------------------------------
Welcome to the IDUG DB2-L list. To unsubscribe, go to the archives and home page at http://www.idugdb2-l.org/archives/db2-l.html. From that page select "Join or Leave the list". If you will be out of the office, send the SET DB2-L NO MAIL command to [login to unmask email] The IDUG List Admins can be reached at [login to unmask email] Find out the latest on IDUG conferences at http://conferences.idug.org/index.cfm

John W Amsden

Re: "PUBLIC" group in DB2 - a close look into it
(in response to Georg Peter)
Interesting discussion as we are in the middle of changing our security here. We do have some
tables available to "public". We found one thing different than what has been declared -
"RACF checks that the ID is authorized for DB2 resources and permits, or does not permit, access to DB2." and that is that RACF must be told to check access to a DB2 subsystem - it does not do it
"out of the box". There was an assumption at my workplace that RACF treated any DB2 subsystem
as a "closed situation" i.e. that if you didn't permit access to the subsystem then you were denied. Not true!!!!! We had to add the subsystem names to a RACF table before they were checked.

-----Original Message-----
From: Clayton, Colin [mailto:[login to unmask email]
Sent: Wednesday, December 03, 2003 6:59 AM
To: [login to unmask email]
Subject: Re: "PUBLIC" group in DB2 - a close look into it




Emad,

as you say, its not a trivial question and I don't want to sound as if I am fobbing you off with the RTFM answer, however... I'd suggest you read Part 3 of the DB2 Admin Guide. The quoted text is copied from there.

"You can grant privileges to the ID PUBLIC, making them available to all IDs at the local DB2." - The responsibility is with you, as the security administrator, to ensure that any access to DB2 is controlled by your security software - RACF / ACF2 etc.

"Whether or not a process can gain access to a specific DB2 subsystem can be controlled outside of DB2. A common procedure is to grant access only through
RACF or some similar security system. Profiles for access to DB2 from various environments, and DB2 address spaces, are defined as resources to RACF. Each
request to access DB2 is associated with an ID. RACF checks that the ID is authorized for DB2 resources and permits, or does not permit, access to DB2."

I'd also be surprised if any of your sensitive data is open to PUBLIC access. In most sites I have seen, PUBLIC is only ever used on development or test subsystems. In production environments access is granted to specific RACF secondary authids and usually only allows access to the data via an application program since you do not want anyone running 'ad hoc' updates to the data.

You should also read Chapter 18 "Controlling inbound connections that use TCP/IP protocols".

Colin





--------------------------------------------------------------------------------- Welcome to the IDUG DB2-L list. To unsubscribe, go to the archives and home page at http://www.idugdb2-l.org/archives/db2-l.html. From that page select "Join or Leave the list". If you will be out of the office, send the SET DB2-L NO MAIL command to [login to unmask email] The IDUG List Admins can be reached at [login to unmask email] Find out the latest on IDUG conferences at http://conferences.idug.org/index.cfm


---------------------------------------------------------------------------------
Welcome to the IDUG DB2-L list. To unsubscribe, go to the archives and home page at http://www.idugdb2-l.org/archives/db2-l.html. From that page select "Join or Leave the list". If you will be out of the office, send the SET DB2-L NO MAIL command to [login to unmask email] The IDUG List Admins can be reached at [login to unmask email] Find out the latest on IDUG conferences at http://conferences.idug.org/index.cfm

cliff boley

Re: "PUBLIC" group in DB2 - a close look into it
(in response to John W Amsden)
Emad,

I don't like public, although we do use it (it was that way when I got here)
.

As Stephen said anyone with a valid TSO userid/password can use public
objects.
Most applications/tables are created with a group of users in mind and in
most shops that group has TSO IDs and
are assigned to a security (RACF etc.) groups so give only those groups
access. Granting public is saying " I don't know who is coming in and I
don't care"

We do have Web applications that anyone can use (the public, we're a state
agency) but we created a RACF userid and groups for use by those
applications and grant the Web groups only the access to DB2 objects that
the application needs.

That way any dude on the street can't go wondering around our database,
"except" for PUBLIC objects.

Even the development/test groups don't need public. All developers should be
in a RACF group already, so grant
their group access the their objects. That prevents application group A
from stepping on application group Bs objects..

I can't think of any reason to grant PUBLIC, except that its expedient.

That said we're guilt of using it and I'd like to get rid of it but that's
going to take a bit of work. Best not to get started in the first place.

cliff:-)



-----Original Message-----
From: Amsden, John W [mailto:[login to unmask email]
Sent: Wednesday, December 03, 2003 5:21 AM
To: [login to unmask email]
Subject: Re: "PUBLIC" group in DB2 - a close look into it


Interesting discussion as we are in the middle of changing our security
here. We do have some
tables available to "public". We found one thing different than what has
been declared -
"RACF checks that the ID is authorized for DB2 resources and permits, or
does not permit, access to DB2." and that is that RACF must be told to check
access to a DB2 subsystem - it does not do it
"out of the box". There was an assumption at my workplace that RACF treated
any DB2 subsystem
as a "closed situation" i.e. that if you didn't permit access to the
subsystem then you were denied. Not true!!!!! We had to add the subsystem
names to a RACF table before they were checked.

-----Original Message-----
From: Clayton, Colin [mailto:[login to unmask email]
Sent: Wednesday, December 03, 2003 6:59 AM
To: [login to unmask email]
Subject: Re: "PUBLIC" group in DB2 - a close look into it




Emad,

as you say, its not a trivial question and I don't want to sound as if I am
fobbing you off with the RTFM answer, however... I'd suggest you read Part 3
of the DB2 Admin Guide. The quoted text is copied from there.

"You can grant privileges to the ID PUBLIC, making them available to all IDs
at the local DB2." - The responsibility is with you, as the security
administrator, to ensure that any access to DB2 is controlled by your
security software - RACF / ACF2 etc.

"Whether or not a process can gain access to a specific DB2 subsystem can be
controlled outside of DB2. A common procedure is to grant access only
through
RACF or some similar security system. Profiles for access to DB2 from
various environments, and DB2 address spaces, are defined as resources to
RACF. Each
request to access DB2 is associated with an ID. RACF checks that the ID is
authorized for DB2 resources and permits, or does not permit, access to
DB2."

I'd also be surprised if any of your sensitive data is open to PUBLIC
access. In most sites I have seen, PUBLIC is only ever used on development
or test subsystems. In production environments access is granted to specific
RACF secondary authids and usually only allows access to the data via an
application program since you do not want anyone running 'ad hoc' updates to
the data.

You should also read Chapter 18 "Controlling inbound connections that use
TCP/IP protocols".

Colin





----------------------------------------------------------------------------
----- Welcome to the IDUG DB2-L list. To unsubscribe, go to the archives and
home page at http://www.idugdb2-l.org/archives/db2-l.html. From that page
select "Join or Leave the list". If you will be out of the office, send the
SET DB2-L NO MAIL command to [login to unmask email] The IDUG List
Admins can be reached at [login to unmask email] Find out the
latest on IDUG conferences at http://conferences.idug.org/index.cfm

----------------------------------------------------------------------------
----- Welcome to the IDUG DB2-L list. To unsubscribe, go to the archives and
home page at http://www.idugdb2-l.org/archives/db2-l.html. From that page
select "Join or Leave the list". If you will be out of the office, send the
SET DB2-L NO MAIL command to [login to unmask email] The IDUG List
Admins can be reached at [login to unmask email] Find out the
latest on IDUG conferences at http://conferences.idug.org/index.cfm


---------------------------------------------------------------------------------
Welcome to the IDUG DB2-L list. To unsubscribe, go to the archives and home page at http://www.idugdb2-l.org/archives/db2-l.html. From that page select "Join or Leave the list". If you will be out of the office, send the SET DB2-L NO MAIL command to [login to unmask email] The IDUG List Admins can be reached at [login to unmask email] Find out the latest on IDUG conferences at http://conferences.idug.org/index.cfm

Marcel Harleman

Re: "PUBLIC" group in DB2 - a close look into it
(in response to cliff boley)
On Wed, 3 Dec 2003 14:10:31 +0300, you wrote:

>(...)
>
>- Does "PUBLIC" mean everybody from anywhere? or only those user-IDs defined by the security system (in our case is ACF2)?
>- If ACF2 doesn't permit a user's access, can we guarantee that this user cannot access any DB2 "PUBLIC" tables?
>- Assuming "PUBLIC" as a group, can we change/define the users which belong to this group?
>
>What I need is a deeper look inside the special DB2 group called "PUBLIC", in case you know any reference to help me, please let me know.
>
>Why "PUBLIC" is a concern to me?
>Shortly we will be opening our network to the Internet, so Internet users will access Web applications which access DB2 on the mainframe. We need to make sure that no Internet hacker can access our DB2 through the "PUBLIC" group.
>
>Any help appreciated. Thanks...
>
Hi Emad,

PUBLIC is not a group. I'm not familiar with ACF2, but RACF does have
an equivalent: UNIVERSAL ACCESS, which can be everything from NONE to
ALTER.

PUBLIC access does mean that everybody with access to that DB2
subsystem can perform the granted action. That is not necessarily
restricted to those userid's defined by the security system, that
depends on what you have permitted through certain ZPARM values for
DDF, if you use that.

I don't know what you are going to use to make DB2 "internet
accessible" but I'm pretty sure that most people who are going to
connect are NOT in your security system.
It is of course possible that internet users get in through an
application that has it's own verified userid (so you can use that
userid in your security implementation) but if it's being done through
an application or connection that has no verified userid then that
means that you only can use PUBLIC (since they don't have a userid
then).

My recommendation would be to make a "PUBLIC" group (of course with
another name than PUBLIC (f.i. a group <db2id>ALL) and make "PUBLIC"
tables accessible through that group; you could even give every
verified user access to that particular DB2 through that group so it
truly is PUBLIC on a local basis. The GRANT TO PUBLIC then is only
allowed for those plans and packages that have to be accessible for
the rest of the world that connects via internet without verified
users.

Just my humble thoughts on the subject.

Marcel.

---------------------------------------------------------------------------------
Welcome to the IDUG DB2-L list. To unsubscribe, go to the archives and home page at http://www.idugdb2-l.org/archives/db2-l.html. From that page select "Join or Leave the list". If you will be out of the office, send the SET DB2-L NO MAIL command to [login to unmask email] The IDUG List Admins can be reached at [login to unmask email] Find out the latest on IDUG conferences at http://conferences.idug.org/index.cfm

Elmer J. Valenzuela

Re: "PUBLIC" group in DB2 - a close look into it
(in response to Marcel Harleman)
Hello,

-"PUBLIC" means any defined DB2 user
-Not familiar with ACF2 but assuming it has the same functionality and logic as RACF,
then you can rely on it only if you migrate your security definitions from DB2 to ACF/2.
This means having to define all DB2 resources to ACF/2. (I don't think this is advisable).
-"PUBLIC" in itself is not a group although technically its the 'whole group' of all DB2 defined users.

How is your DB2 going to be accessed from the network? If it is through an
application that has a hard-coded DB2 userid inside it, then the PUBLIC
concern is of no use because anyone who has access to the application
would hide behind the authorized id thus bypassing any restriction you
would put on PUBLIC.

My 2cworth.
../elmer
> Hi DB2-Lers,
>
> DB2 v7 for OS/390 with ACF2.
>
> My question may look a trivial one, but I need a close look at it.
> The "PUBLIC" group known in DB2 which covers all local users in a DB2 > server.
> I have some questions about it:
>
> - Does "PUBLIC" mean everybody from anywhere? or only those user-IDs > defined by the security system (in our case is ACF2)?
> - If ACF2 doesn't permit a user's access, can we guarantee that this > user cannot access any DB2 "PUBLIC" tables?
> - Assuming "PUBLIC" as a group, can we change/define the users which > belong to this group?
>
> What I need is a deeper look inside the special DB2 group called > "PUBLIC", in case you know any reference to help me, please let me know.
>
> Why "PUBLIC" is a concern to me?
> Shortly we will be opening our network to the Internet, so Internet > users will access Web applications which access DB2 on the mainframe. We > need to make sure that no Internet hacker can access our DB2 through the > "PUBLIC" group.
>
> Any help appreciated. Thanks...
>
> ---------------------------------------------------------------------------------
> Welcome to the IDUG DB2-L list. To unsubscribe, go to the archives and home page at http://www.idugdb2-l.org/archives/db2-l.html. From that page select "Join or Leave the list". If you will be out of the office, send the SET DB2-L NO MAIL command to [login to unmask email] The IDUG List Admins can be reached at [login to unmask email] Find out the latest on IDUG conferences at http://conferences.idug.org/index.cfm
>

---------------------------------------------------------------------------------
Welcome to the IDUG DB2-L list. To unsubscribe, go to the archives and home page at http://www.idugdb2-l.org/archives/db2-l.html. From that page select "Join or Leave the list". If you will be out of the office, send the SET DB2-L NO MAIL command to [login to unmask email] The IDUG List Admins can be reached at [login to unmask email] Find out the latest on IDUG conferences at http://conferences.idug.org/index.cfm