setuid for dbaccess
A DBA needed production tables and procedures to be owned by informix, but wanted other users to create them without the informix password. His setuid-to-informix shell script calling dbaccess failed (others reported error -387 No connect permission), and granting DBA to a role didn't work. Jonathan Leffler explained Informix checks the real UID, not the effective UID, so plain SUID has no effect; only a SUID-root program that sets both real and effective UID to informix works (he offered his 'runixcmd' tool). He also noted DBAs can simply issue CREATE TABLE/PROCEDURE "informix".name. Another suggestion was a daemon running as informix that picks up SQL files from a drop directory, with warnings about the security risk; the thread then drifted into debate over whether developers should create stored procedures.
Auto-generated by DrWatson from the posts below — may be imperfect; read the full thread.
I have a requirement that all production tables and stored procedures
be
owned by informix.
Yet there is also a requirement that a number of users need to be able
to create them.
And these users cannot know the informix password. I was hoping to set
up a script that
would be suid to informix and allow these users to run this script which
would
call dbaccess and process a stored sql file containg the appropriate
create statements.
This doesn't appear to work. Is there something in dbaccess that would
prevent this????
I know my set uid script is working because I touch a file and it is
owned by informix and
not the user executing the script.
I am running IDS 9.4 on HPUX 11.
I tried an alternative of using roles to do this, but I can't seem to
grant dba authority to a role.
Thanks in advance for any ideas on this, or any alternatives to solve my
problem.....mick
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Mick Putillo, Senior Technical Architect
ChevronTexaco=20
Fuel and Marine Marketing LLC, Information Technology
44 South Broadway, Room 620, White Plains, NY 10601
Tel 914-285-7367 (CTN 285-7367) Fax 914-285-7310
mailto: MickPutillo@chevrontexaco.com
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
one way is to write a shell script which will run as a deamon
process of user informix. There should be a designated directory
where users/developers should keep their stored procedures as a
text file. The shell script will check that directory every minute
and if a file exists, create a stored procedure from that file.
Warning: This can be a serious security hazard. anyone can write
a malacious code inside a SP (like dropping a table). Creating
a stored procedure should never be allowed to developers.At least
I wouldn't.
----- Original Message -----
From: "Putillo, Mick J" <MickPutillo@chevrontexaco.com>
To: <ids@iiug.org>
Sent: November 11, 2003 08:40
Subject: setuid for dbaccess [2157]
> I have a requirement that all production tables and stored procedures be
> owned by informix.
> Yet there is also a requirement that a number of users need to be able
> to create them.
> And these users cannot know the informix password. I was hoping to set
> up a script that
> would be suid to informix and allow these users to run this script which
> would
> call dbaccess and process a stored sql file containg the appropriate
> create statements.
> This doesn't appear to work. Is there something in dbaccess that would
> prevent this????
> I know my set uid script is working because I touch a file and it is
> owned by informix and
> not the user executing the script.
>
> I am running IDS 9.4 on HPUX 11.
>
> I tried an alternative of using roles to do this, but I can't seem to
> grant dba authority to a role.>
> Thanks in advance for any ideas on this, or any alternatives to solve my
> problem.....mick
>
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> Mick Putillo, Senior Technical Architect
>
> ChevronTexaco=20
> Fuel and Marine Marketing LLC, Information Technology
> 44 South Broadway, Room 620, White Plains, NY 10601
> Tel 914-285-7367 (CTN 285-7367) Fax 914-285-7310
>
> mailto: MickPutillo@chevrontexaco.com
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>
>
>
>
Mick,
I've got a similar situation and have also tried to change the effective
user for cases such as this.
I've set permissions on a script via:
chmod 7511 scriptfile
When testing, I had the following in my script:
touch myfile
whoami
who am i
dbaccess ...
myfile file is created with the effective user as the owner.
whoami shows the effective user's name.
who am i shows the original user's name.
dbaccess works fine when running as informix.
dbaccess fails when running as another user -- 387: No connect
permission
I think the fact that you see the original user's name via "who am i"
tells you that dbaccess is probably looking at the actual user id, not
the effective user id. Are doing something similar to this or did you
go about it another way?
I am running IDS 9.3 on Solaris versions 2.7 and 2.8.
Does anyone else have any suggestions to get around this issue?
Gary Andrus
Database Administrator
Aetna-InteliHealth
-----Original Message-----
From: Putillo, Mick J [mailto:MickPutillo@chevrontexaco.com]
Sent: Tuesday, November 11, 2003 8:40 AM
To: ids@iiug.org
Subject: setuid for dbaccess [2157]
I have a requirement that all production tables and stored procedures be
owned by informix.
Yet there is also a requirement that a number of users need to be able
to create them.
And these users cannot know the informix password. I was hoping to set
up a script that
would be suid to informix and allow these users to run this script which
would
call dbaccess and process a stored sql file containg the appropriate
create statements.
This doesn't appear to work. Is there something in dbaccess that would
prevent this????
I know my set uid script is working because I touch a file and it is
owned by informix and
not the user executing the script.
I am running IDS 9.4 on HPUX 11.
I tried an alternative of using roles to do this, but I can't seem to
grant dba authority to a role.
Thanks in advance for any ideas on this, or any alternatives to solve my
problem.....mick
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Mick Putillo, Senior Technical Architect
ChevronTexaco=20
Fuel and Marine Marketing LLC, Information Technology
44 South Broadway, Room 620, White Plains, NY 10601
Tel 914-285-7367 (CTN 285-7367) Fax 914-285-7310
mailto: MickPutillo@chevrontexaco.com
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Agreed....
-----Original Message-----
From: Ravi Krishna [mailto:rkrishna@farelogix.com]
Sent: Tuesday, November 11, 2003 10:32 AM
To: ids@iiug.org
Subject: Re: setuid for dbaccess [2158]
one way is to write a shell script which will run as a deamon process of
user informix. There should be a designated directory where users/developers
should keep their stored procedures as a text file. The shell script will
check that directory every minute and if a file exists, create a stored
procedure from that file.
Warning: This can be a serious security hazard. anyone can write a malacious
code inside a SP (like dropping a table). Creating a stored procedure should
never be allowed to developers.At least I wouldn't.
----- Original Message -----
From: "Putillo, Mick J" <MickPutillo@chevrontexaco.com>
To: <ids@iiug.org>
Sent: November 11, 2003 08:40
Subject: setuid for dbaccess [2157]
> I have a requirement that all production tables and stored procedures
> be owned by informix. Yet there is also a requirement that a number of
> users need to be able to create them.
> And these users cannot know the informix password. I was hoping to set
> up a script that
> would be suid to informix and allow these users to run this script which
> would
> call dbaccess and process a stored sql file containg the appropriate
> create statements.
> This doesn't appear to work. Is there something in dbaccess that would
> prevent this????
> I know my set uid script is working because I touch a file and it is
> owned by informix and
> not the user executing the script.
>
> I am running IDS 9.4 on HPUX 11.
>
> I tried an alternative of using roles to do this, but I can't seem to
> grant dba authority to a role.>
> Thanks in advance for any ideas on this, or any alternatives to solve
> my problem.....mick
>
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
> 3D=3D=
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> Mick Putillo, Senior Technical Architect
>
> ChevronTexaco=20
> Fuel and Marine Marketing LLC, Information Technology
> 44 South Broadway, Room 620, White Plains, NY 10601
> Tel 914-285-7367 (CTN 285-7367) Fax 914-285-7310
>
> mailto: MickPutillo@chevrontexaco.com
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
> 3D=3D=
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>
>
>
>
"CONFIDENTIALITY NOTICE: This message originates from WHSmith USA Travel
Retail. This email message and all attachments may contain legally
privileged and confidential information intended solely for the use of the
addressee. If you are not the intended recipient, you should immediately
stop reading this message and delete it from the system. Any unauthorized
reading, distribution, copying, or other use of this message or its
attachments is strictly prohibited. All personal messages express solely the
sender's views and not those of WHSmith USA Travel Retail. This message may
not be copied or distributed without this disclaimer."
Your DBAs can do CREATE PROCEDURE "informix".whatnot(...)... and CREATE
TABLE "informix".whosit(...).
Don't trust SUID scripts unless you know a lot more about your system than
I do. I wouldn't trust them even then.
For primarily historical reasons, Informix only pays attention to the real
UID, not the effective UID, when you connect to the database.
Simply making any program (shell script or executable) SUID has no effect.
The only way to achieve the change is by making the program SUID root and
making the program set the real and effective UID to informix. Only root
can do that.
I have a program that I call runixcmd (run Informix command) that is
intended to be a SUID root program that runs specific Informix commands as
user informix. It can be compiled to limit who can do what - it is quite
restrictive by default and can be configured to be either more or less
restrictive. By default, it requires that you remove the public
permissions from the secured commands, and so on.
If you want to look at the code, contact me - it would be about 10 kB of
gzipped tar file (not exorbitant, but I don't know that it would be
acceptable just to post it to this list).
--
Jonathan Leffler (jleffler@us.ibm.com)
STSM, Informix Database Engineering, IBM Data Management
4100 Bohannon Drive, Menlo Park, CA 94025
Tel: +1 650-926-6921 Tie-Line: 630-6921
"I don't suffer from insanity; I enjoy every minute of it!"
|---------+------------------------------->
| | "Putillo, Mick J" |
| | <MickPutillo@chevron|
| | texaco.com> |
| | Sent by: |
| | forum.subscriber@iiu|
| | g.org |
| | |
| | |
| | 11/11/2003 05:40 AM |
|---------+------------------------------->
>-------------------------------------------------------------------------------
--------------------------------------------------------------|
| |
| To: ids@iiug.org |
| cc: |
| Subject: setuid for dbaccess [2157] |
>-------------------------------------------------------------------------------
--------------------------------------------------------------|
I have a requirement that all production tables and stored procedures be
owned by informix.
Yet there is also a requirement that a number of users need to be able
to create them.
And these users cannot know the informix password. I was hoping to set
up a script that
would be suid to informix and allow these users to run this script which
would
call dbaccess and process a stored sql file containg the appropriate
create statements.
This doesn't appear to work. Is there something in dbaccess that would
prevent this????
I know my set uid script is working because I touch a file and it is
owned by informix and
not the user executing the script.
I am running IDS 9.4 on HPUX 11.
I tried an alternative of using roles to do this, but I can't seem to
grant dba authority to a role.
Thanks in advance for any ideas on this, or any alternatives to solve my
problem.....mick
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Mick Putillo, Senior Technical Architect
ChevronTexaco=20
Fuel and Marine Marketing LLC, Information Technology
44 South Broadway, Room 620, White Plains, NY 10601
Tel 914-285-7367 (CTN 285-7367) Fax 914-285-7310
mailto: MickPutillo@chevrontexaco.com
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
That's
an interesting comment about developers creating stored procedures.
While I wouldn't expect all developers to know all about database
administration, shouldn't they have enough knowledge of the database and
good database design to be capable of writing a stored procedure?
And wouldn't the better ones be capable of database administration?
In my limited experience, at places where DBA's are separate and distinct
from Developers, the DBAs know next to nothing about the application, and
very little about relationships between tables.
----- Original Message -----
From: "Ravi Krishna" <rkrishna@farelogix.com>
To: <ids@iiug.org>
Sent: Tuesday, November 11, 2003 8:32 AM
Subject: Re: setuid for dbaccess [2158]
> one way is to write a shell script which will run as a deamon
> process of user informix. There should be a designated directory
> where users/developers should keep their stored procedures as a
> text file. The shell script will check that directory every minute
> and if a file exists, create a stored procedure from that file.
>
> Warning: This can be a serious security hazard. anyone can write
> a malacious code inside a SP (like dropping a table). Creating
> a stored procedure should never be allowed to developers.At least
> I wouldn't.
>
>
Danny,
I don't quite agree with you. In order for DBA to perform his duties
well, he/she must know the application well. Things like extent size
allocation, creation of indexes etc are all application dependent.
Regarding developers writing stored procedure themselves: The skill set for
writing good SQL is different from JAVA programmers and from my experience,
I don't see JAVA programmers as proficient in SQL/Database concepts as
DBAs are.
Ravi
----- Original Message -----
From: "Danny Wright" <dwright@sherwoodfoods.com>
To: "Ravi Krishna" <rkrishna@farelogix.com>; <ids@iiug.org>
Sent: Tuesday, November 11, 2003 19:43
Subject: Re: setuid for dbaccess [2158]
> That's an interesting comment about developers creating stored procedures.
>
> While I wouldn't expect all developers to know all about database
> administration, shouldn't they have enough knowledge of the database and
> good database design to be capable of writing a stored procedure?
>
> And wouldn't the better ones be capable of database administration?
>
> In my limited experience, at places where DBA's are separate and distinct
> from Developers, the DBAs know next to nothing about the application, and
> very little about relationships between tables.
>
>
>
> ----- Original Message -----
> From: "Ravi Krishna" <rkrishna@farelogix.com>
> To: <ids@iiug.org>
> Sent: Tuesday, November 11, 2003 8:32 AM
> Subject: Re: setuid for dbaccess [2158]
>
>
> > one way is to write a shell script which will run as a deamon
> > process of user informix. There should be a designated directory
> > where users/developers should keep their stored procedures as a
> > text file. The shell script will check that directory every minute
> > and if a file exists, create a stored procedure from that file.
> >
> > Warning: This can be a serious security hazard. anyone can write
> > a malacious code inside a SP (like dropping a table). Creating
> > a stored procedure should never be allowed to developers.At least
> > I wouldn't.
> >
> >
>
>