SCO at job vs. Informix

SCO at job vs. Informix

Post by Colonel Pan » Wed, 10 Jun 1992 11:36:49




Quote:>System:  SCO Unix 3.2.2, Informix database

What version of ESQL/C and of SE???

Quote:>We are trying to schedule an Informix (ESQL/C)-using process for
>execution with the at command.  The problem is:

>    - when the job is executed by cron via at, access to the
>      database is not allowed if run under any id other than root

>These same ids are able to execute the very same program successfully
>from the command line.

>We have checked the enviromental variables (which are correct) and
>the user/group id assigned the job by at (which are also correct).

Are you *sure*?  Not being familiar with how SCO's at(1) handles the
uid issues, I don't even know the right questions to ask.  You don't have
any of the C2 stuff enabled, do you?

Try dumping your env variables (INFORMIXDIR, PATH [if used], DBPATH, SQLEXEC,
etc.]) from within your program to make sure at isn't doing something you
didn't expect.

Quote:>I dont know if Informix is checking something other than the u/gid
>to determine the user or what, but we absolutely cannot access the
>db under a non-root id, even after granting dba privledges to all.

We reset ruid and euid; also, the engine process runs as gid "informix".

Quote:>Informix tech support has not been of any help so far.

>Has anyone else seen anything like this???

I haven't heard of any problems when C2 is properly relaxed.

>Thanks!
>Mike Suter


--

  Smith and Wesson: the Ultimate Point-and-Click User Interface.

 
 
 

SCO at job vs. Informix

Post by Mike Sut » Fri, 12 Jun 1992 23:40:06


Alan,

Quote:>What version of ESQL/C and of SE???

Our isql indicates 4.00.UG2 on the startup banner.

Quote:>>We are trying to schedule an Informix (ESQL/C)-using process for
>>execution with the at command.  The problem is:

>>        - when the job is executed by cron via at, access to the
>>          database is not allowed if run under any id other than root

>>These same ids are able to execute the very same program successfully
>>from the command line.

>>We have checked the enviromental variables (which are correct) and
>>the user/group id assigned the job by at (which are also correct).
>Are you *sure*?  Not being familiar with how SCO's at(1) handles the
>uid issues, I don't even know the right questions to ask.  You don't have
>any of the C2 stuff enabled, do you?

No, we are not using the C2 stuff.  To check the id and environment
of the job, we dumped the output of id, env, and pwd given by at and
all three came up correct.

Quote:>Try dumping your env variables (INFORMIXDIR, PATH [if used], DBPATH, SQLEXEC,
>etc.]) from within your program to make sure at isn't doing something you
>didn't expect.

Already did; everything comes out identical to the user's interactive
session (under which the program runs successfully).

Quote:>>I dont know if Informix is checking something other than the u/gid
>>to determine the user or what, but we absolutely cannot access the
>>db under a non-root id, even after granting dba privledges to all.
>We reset ruid and euid; also, the engine process runs as gid "informix".

 ^^^^^^^^^^^^^^^^^^^^^^
In that case, what do you use to determine the uid/gid?

Quote:>I haven't heard of any problems when C2 is properly relaxed.

As above, we are not using C2.

Thanks for your response!

Mike Suter


 
 
 

1. It isn't about SCO vs IBM, it is about SCO vs Linux

We have to remember, SCO's suit against IBM is not about Linux, it is about
a contract dispute and IBM's behaviour.

It may very well be that there is a basis for SCO's complaint. I know this
is a far fetched view, but remember, it is not about the legality of the IP
in Linux, it is about a contract with IBM.

So, everyone is saying that IBM will trounce SCO. Well, sure, probably. That
is not the issue. SCO has claimed IP in Linux, this claim seems unbounded
to the IBM complaint. They are also implying that people who have been
exposed to legacy UNIX have contributed code to Linux.

So, while it is nice to think of IBM as a white knight, I'm not sure we
should be so sure of our situation in that respect.

I am 100% positive that Linux is safe and clean and perfectly legit, but the
finer details could be confusing to a jury.

2. index.html default

3. BENCHMARKS - SCO vs Solaris vs Unixware vs etc...

4. help! debian install freakin'

5. Jobs, Jobs, Jobs And More Jobs!!!

6. Why are M$ users significantly slower (was pee pee pee)

7. Maxtor UltraATA/100 PCI