Path: utzoo!attcan!uunet!snorkelwacker!apple!oliveb!pyramid!infmx!aland
From: aland@infmx.UUCP (Dr. Scump)
Newsgroups: comp.databases
Subject: Re: Bug creating a db in Informix
Summary: different issue
Message-ID: <3822@infmx.UUCP>
Date: 7 Apr 90 01:27:41 GMT
References: <1990Apr3.175133.12382@aqdata.uucp> <427@mlacus.oz>
Reply-To: aland@infmx.UUCP (alan denney)
Organization: INFORMIX Professional Services ("Peace thru Normalization")
Lines: 34

In article <427@mlacus.oz> nick@mlacus.oz (Nick Langmaid) writes:
>We've experienced that problem here.  The explanation we came up with

Again, I can't reproduce the original referenced problem.  If someone
can give me a command sequence that does reproduce it, I'll check it
out.

>was that the Informix software spawns a task which changes its group
>to "Informix", but preserves its userid.  As a result, any group 

In a sense.  Each front-end (ISQL, esql program, 4GL program, etc.)
spawns an engine process which runs with uid=(user's uid) and
gid=informix.  That way, you don't have to mess with filesystem
permissions for multiuser databases.  Databases are always created
w/ permissions 660, owner= creating user, group= informix.

>permission you grant (other than to "Informix") are more or less
>irrelevant.  User permissions still apply.

Huh?  

>I can't claim that this is a complete and accurate explanation,
>because once we had a workaround we stopped looking at it.
>
>Hope this helps,
>Nick Langmaid       ACUS      Tel: +61(3)823-1035        Fax: +61(3)267-4692

--
Alan S. Denney  @  Informix Software, Inc.       "We're homeward bound
aland@informix.com  {pyramid|uunet}!infmx!aland   ('tis a damn fine sound!)
-----------------------------------------------   with a good ship, taut & free
 Disclaimer:  These opinions are mine alone.      We don't give a damn, 
 If I am caught or killed, the secretary          when we drink our rum
 will disavow any knowledge of my actions.        with the girls of old Maui."