Path: utzoo!attcan!uunet!husc6!bbn!rochester!pt.cs.cmu.edu!cadre!pitt!darth!investor!news
From: news@investor.UUCP ( Bob Peirce)
Newsgroups: comp.databases
Subject: Re: Restricting access to Informix tables
Message-ID: <1084@investor.UUCP>
Date: 20 May 89 15:36:17 GMT
References: <1080@investor.UUCP> <1092@altos86.UUCP> <1347@infmx.UUCP>
Reply-To: rbp@investor.UUCP (Bob Peirce #305)
Organization: Cookson, Peirce & Co., Pittsburgh, PA
Lines: 82

In article <1347@infmx.UUCP> aland@infmx.UUCP (alan denney) writes:
>In article <1092@altos86.UUCP> jon@altos86.UUCP (Jonathan Ma) writes:
>>In article <1080@investor.UUCP> news@investor.UUCP ( Bob Peirce) 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.  
>>
>>	You can do the following as root:
>>	% cd $INFORMIXDIR/bin
>>	% chmod 500 sperform
>>
>
>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().
>
Sorry doctor, but that was the first thing we tried.  In fact all our
database applications are owned by dbm.  4gl apparently considers
the real ID and not the effective ID and only root can change the real
ID.  Furthermore, 4gl apparently gets control very early making it
impossible to change the real ID even if you are root.

We have a solution which came from a gentleman at NCR near Boulder,  CO. 
Unfortunately I did not write down his name or site when he called so I
cannot give proper attribution.  However, the essence of the procedure is
to have a C routine file, part of which has your ID setting routines. 
Then have a shell script which runs after main.4gl finally gets to
main.c which goes into main.c and inserts a call to the setid function
before the first 4gl function call.  We put this in the makefile so the
whole thing works automatically.  Make the final program owned by root
and run suid.  The pertinent part of our makefile now looks like this.

#  makefile for invest 4gl program

FGLC = /usr/informix/lib/fglc
FGLC2 = /usr/informix/lib/fglc2 -4GL
CFLAGS = -I/usr/informix/incl
LD = /usr/informix/lib
LIB = ${LD}/lib4gl.a ${LD}/libforms.a ${LD}/libsql.a

...  Other stuff

invest.ec: invest.4gl
	$(FGLC) invest.4gl
invest.c: invest.ec
	$(FGLC2) invest.ec
invest.o: invest.c
	sh fix-invest.c
	cc $(CFLAGS) -c invest.c

...  Even more stuff


And fix-invest.c looks like this:

cp invest.c invest.b
sed < invest.b > invest.c -e '/fgl_init/i\
setids();

'
rm invest.b

Fgl_init is the first 4gl routine called, at least in this progarm and
probably in all 4gl programs.  Thus the C function, setids(), gets run
before fgl_init can run.  It changes the real and effective IDs to dbm
so fgl_init can't do anything about it.

There is one security hole.  We provide shell escapes.  Unfortunately,
once root has set the ID to dbm, dbm can't reset it to the real user.  I
suppose we could get around this by forking the program and running the
parent as root and the child as dbm.  Unfortunately, that is too hairy
for my meager C coding skills, so we just trap out the shell escapes so
only a limited list of users can use them.  This is hardwired in, not a
good idea, but easy and this won't require much change.

All in all a nice solution to a tricky problem.  Thanks, whoever you were!

-- 
Bob Peirce, Pittsburgh, PA				 412-471-5320
uucp: ...!{allegra, bellcore, cadre, idis, psuvax1}!pitt!investor!rbp
	    NOTE:  Mail must be < 30K  bytes/message