Path: utzoo!attcan!uunet!mcvax!ukc!reading!riddle!john
From: john@riddle.UUCP (Jonathan Leffler)
Newsgroups: comp.databases
Subject: Re: Restricting access to Informix tables
Message-ID: <1021@riddle.UUCP>
Date: 22 May 89 08:47:40 GMT
References: <1080@investor.UUCP> <1092@altos86.UUCP> <1347@infmx.UUCP>
Reply-To: john@sphinx.co.uk (Jonathan Leffler)
Organization: Sphinx Ltd., Maidenhead, England
Lines: 58

In article <1347@infmx.UUCP> aland@infmx.UUCP (alan denney) writes:
>>>We have a database we want to keep most people from updating or
>>>inserting except under controlled circumstances; ie, No from sperform,
>>>but YES from a 4GL data entry program.  
>
>The only way to get the desired functionality that I know of (in UNIX)
>is to create a "phony" generic user name for the application,
>grant it the appropriate database permissions, make it the program 
>owner, and use setuid().
>

Unfortunately, setuid programs do not work with Informix, unless
they are setuid root!

Reasoning:
John is logged in as john/consult (uid=504, euid=504, gid=500, egid=500)
Program is owned dbappl/dbappl (uid=70, gid=70, perms=6511 -- setuid dbappl)
John runs Program: process has perms (uid=504, euid=70, gid=500, egid=70)
SQLEXEC is owned root/informix (uid=0, gid=50, perms=6511 -- setuid root)
Program runs SQLEXEC: process has perms (uid=504, euid=0, gid=500, egid=50)

Problem: SQLEXEC only knows about the real UID of John, not the
intermediate user dbappl. 

Comment { no flames on this bit, please }:
No criticism intended of anybody -- its just a fact of UNIX life that 
setuid programs cannot run other setuid programs and hand on the first 
setuid ownership.  It is an interesting question whether the permissions 
should be handed on automatically?  There are arguments for and against, 
and I suspect that it should be an option, a new file permission.  
However, as UNIX has survied for a while without it, I don't suppose 
anything will be done to fix this problem, even if it is admitted to be a 
problem by the powers that be.
End of comment {end of flame-proof section}.

Circumvention: Program has to be owned root, setuid root; it has
to look up the real UID of dbappl (getpwnam(3)) and do a
setuid(2).  Because EUID is 0, this will set *BOTH* euid and uid,
giving the revised reasoning:

John is logged in as john/consult (uid=504, euid=504, gid=500, egid=500)
Program is owned root/dbappl (uid=0, gid=70, perms=6511 -- setuid dbappl)
John runs Program: process has perms (uid=504, euid=0, gid=500, egid=70)
Program does setuid: process has perms (uid=70, euid=70, gid=500, egid=70)
SQLEXEC is owned root/informix (uid=0, gid=50, perms=6511 -- setuid root)
Program runs SQLEXEC: process has perms (uid=70, euid=0, gid=500, egid=50)

Note: Program has to do its setuid trick prior to opening the
database.

A simpler way of achieving a similar effect is to make people
login as dbappl -- login does the setuid for you and is known to
be (reasonably) reliable.  The profile can be made to run the
application, and only the application, so presumably people can
do no damage with it.  (There weren't any shell escapes, were
there?)

Jonathan Leffler (john@sphinx.co.uk)