Save 
Join IIUG
 for   
 

RSS Feed: IIUG Forum: Classics

More IIUG RSS Feeds

Classics is a forum to discuss all aspects of Informix classic tools including Standard Engine (SE), Online 5, 4GL, D4GL, ESQL, ISQL and others.


URL: http://www.iiug.org/rss/classics.rss

Below is the latest content available from this feed:

New version of old RDS ?
Posted by: pierluigi.frullani@frumar.it (PIERLUIGI FRULLANI) - Wed, 20 Feb 2019 08:48:06 EST
Hi all,



we have ton of code written to work on RDS6 ( fglgo and the like ) and we are

evaluating to refresh a bit the architectures.



Is there such thing as a new version of the old RDS environment ?



Thanks in advance



Pierluigi









* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *



To post a response via email (IIUG members only):



1. Address it to classics@iiug.org

2. Include the bracketed message number in the subject line: [4773]



* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *

ISM question on ism_op
Posted by: jhenry@gwkinvest.com (JOHN HENRY) - Fri, 15 Feb 2019 11:33:01 EST
Hi folks, I'm looking to find an answer to an error I'm getting when trying to

mount a device using the ism_op command.



/backups>ism_op -mount /backups/txlogs

nsrmm: error, cannot open for reading: Bad file number



Does anyone have any insight or suggestions?









* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *



To post a response via email (IIUG members only):



1. Address it to classics@iiug.org

2. Include the bracketed message number in the subject line: [4772]



* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *

Re: i4gl 751 FC2 error at link time
Posted by: eric.vercelletto@begooden-it.com (ERIC VERCELLETTO) - Sat, 15 Dec 2018 12:13:19 EST
Hi all,



self answer: the linux package ncurses-devel was missing. This package does

not seem to be delivered by default on RHEL 7 and needs to be installed.

This should probably be added in the Machnotes: they talk about ubuntu, but

not about RHEL needing this package.

So here is what you need to do on RHEL7, logged as root:

yum install ncurses-devel



And that's it.



BTW, I have been told by a trusted person that a new fickpack on 4GL 75X

should be released by Q1 2019. It will contain a number of fixes, no new

functionality. If you have doubts about issues, time to post tickets urgently

if you want them fixed.



Cheers

Eric









* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *



To post a response via email (IIUG members only):



1. Address it to classics@iiug.org

2. Include the bracketed message number in the subject line: [4771]



* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *

i4gl 751 FC2 error at link time
Posted by: eric.vercelletto@begooden-it.com (ERIC VERCELLETTO) - Mon, 10 Dec 2018 14:43:35 EST
Hi Folks,



yes, me again.



I am compiling an old application developped on an old version of 4gl

(compiled) , and now I am trying to compile it with c4gl 751.FC2 onRed Hat 7



I am now at the stage of linking, and get this error

/bin/ld: /opt/informix/i4gl_7.51.FC2/lib/tools/libnforms.a(cr_put.o):

référence au symbole non défini «tparm»

/bin/ld: note: «tparm» est défini dans le DSO /lib64/libtinfo.so.5 donc

essayez de l'ajouter à la ligne de commande du lieur

/lib64/libtinfo.so.5: could not read symbols: Opération invalide



meaning reference to undefined symbol tparm

note: tparm is defined in the DSO /lib64/libtinfo.so.5, try to add it to the

linker command line.



I am not sure on how to add the reference: is this adding

-ltinfo to the c4gl compile options ?

=> gcc does not understand that syntax



Other solution ?



Thanks

Eric









* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *



To post a response via email (IIUG members only):



1. Address it to classics@iiug.org

2. Include the bracketed message number in the subject line: [4770]



* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *

Re: combining char variables
Posted by: eric.vercelletto@begooden-it.com (ERIC VERCELLETTO) - Tue, 04 Dec 2018 03:24:50 EST
Hi Scott



4.16 is very old, and although the current version 4.51fC2 does not have a lot

more functionality, it will definately have many bug fixes ...



I am at the moment converting an app from 4gl 7.24 (pre ibm) to 7.51. I can

keep you updated on results if you wish.



If you are into 4GL, why don't you take a look at this website



https://kandooerp.org



BR

Eric









* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *



To post a response via email (IIUG members only):



1. Address it to classics@iiug.org

2. Include the bracketed message number in the subject line: [4769]



* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *

test tool for informix 4gl legacy
Posted by: eric.vercelletto@begooden-it.com (ERIC VERCELLETTO) - Tue, 04 Dec 2018 01:59:11 EST
Hi folks,



I had to deal with that question more than 20 years ago and the subject is

coming again.



I have a customer that needs to industrialize scenario tests with a legacy

informix 4gl application( many programs )



So do you know/have you used any testing tools that would record test

scenarios, modify and duplicate them, then play those scenarios?



4gl progs run on linux but are accessed thru putty on windows



any ideas?



thanks bunches

Eric









* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *



To post a response via email (IIUG members only):



1. Address it to classics@iiug.org

2. Include the bracketed message number in the subject line: [4768]



* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *

Re: 4GL Source Control - Linux
Posted by: eric.vercelletto@begooden-it.com (ERIC VERCELLETTO) - Tue, 04 Dec 2018 01:50:56 EST
Hi Eric



git is a good asset with lots of power, though sometimes complex and not easy

to admin.

Svn is efficient and simple but less functionality



Eric









* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *



To post a response via email (IIUG members only):



1. Address it to classics@iiug.org

2. Include the bracketed message number in the subject line: [4767]



* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *

combining char variables
Posted by: scott.roberts@kroger.com (SCOTT ROBERTS) - Wed, 03 Oct 2018 13:41:12 EDT
OK, why does the following syntax work:



let track_statement = text1 clipped, text2 clipped, text3 clipped, text4



but the following only assigns the string from text1 and a syntax error on the

next line.



let track_statement = text1, text2, text3, text4



and



let track_statement = text1 || text2 || text3 || text4

gives me an invalid character error at the first '|'



track_statement is defined as char(250) and the text? variables are char(80)

each.



Is it because the combined strings are too long? Hence they have to be

clipped. Or is the clipped (or some other keyword) required...



Or is it that I'm using the oldest 4GL compiler still in existence. 4.16.UC2

on SCO 3.2.5









* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *



To post a response via email (IIUG members only):



1. Address it to classics@iiug.org

2. Include the bracketed message number in the subject line: [4766]



* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *

PYTHON 3.2 AND ABOVE INTERFACE WITH INFORMIX -....
Posted by: munirspn@yahoo.com (Munir Abdul....) - Wed, 02 May 2018 22:34:59 EDT
sir,



It would be my pleasure to get the information of Python and Informix Database

Interface / requirement for do Data Analytics on Repository available.



Thanks in anticipation



Regards



Munir Abdul AnsariJoint Director(IT)

Government of India, Ministry of Home

AffairsE-mail:munirspn@yahoo.com(Personal)









* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *



To post a response via email (IIUG members only):



1. Address it to classics@iiug.org

2. Include the bracketed message number in the subject line: [4765]



* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *

Re: ESQL/C Programs take very long time to start u
Posted by: david@smooth1.co.uk (david@smooth1.co.uk) - Thu, 19 Apr 2018 14:53:37 EDT
The contents of /proc/self/loginuid IS inherited by child processes, that is

the idea with login id.



The setuid program needs to launch the ESQL/C program, not the shell script.



Currently you have:



shell-->setuid launcher



+->ESQL/C program



what you need is



shell->setuid launcher->ESQL/C program.



A little setuid C progam with an exec at the end...over to Fernando!



Regards,

David.



> On 19 April 2018 at 18:17 RICHARD SPITZ <richard.spitz@med.uni-muenchen.de>

wrote:

>

>

> > In the meantime, I'm thinking about a crude workaround: A little

> > setuid program that reads /proc/self/loginuid. When that yields

> > "4294967295" (= -1), it will write the result of getuid() into

> > that file. When I include that into the shell script just before

> > the ESQL/C program is executed, I hope the loginuid will be inherited

>

> This was, of course, a silly idea. Changing the content of

/proc/self/loginuid

> does not have any effect on child processes.

>

> Looks like i'm stuck here. I'd have to write a pam-enabled program launcher

> that can be configured to use pam_loginuid.so to set the value of

> /proc/self/loginuid, but that's beyond my capability.

>

>

>



>

>









* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *



To post a response via email (IIUG members only):



1. Address it to classics@iiug.org

2. Include the bracketed message number in the subject line: [4764]



* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *

Re: ESQL/C Programs take very long time to start u
Posted by: richard.spitz@med.uni-muenchen.de (RICHARD SPITZ) - Thu, 19 Apr 2018 13:17:54 EDT
> In the meantime, I'm thinking about a crude workaround: A little

> setuid program that reads /proc/self/loginuid. When that yields

> "4294967295" (= -1), it will write the result of getuid() into

> that file. When I include that into the shell script just before

> the ESQL/C program is executed, I hope the loginuid will be inherited



This was, of course, a silly idea. Changing the content of /proc/self/loginuid

does not have any effect on child processes.



Looks like i'm stuck here. I'd have to write a pam-enabled program launcher

that can be configured to use pam_loginuid.so to set the value of

/proc/self/loginuid, but that's beyond my capability.









* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *



To post a response via email (IIUG members only):



1. Address it to classics@iiug.org

2. Include the bracketed message number in the subject line: [4763]



* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *

Re: ESQL/C Programs take very long time to start u
Posted by: domusonline@gmail.com (Fernando Nunes) - Thu, 19 Apr 2018 10:21:11 EDT
Good news. The issue has many formal implications....

The idea behind /proc/self/loginuid is to track the original (really

authenticated user) who launched the program.

Eventually in this scenario if everything was perfect, it would be

"informix". But if it contained that, ESQL/C would think the home of the

user would be ~informix. (it's looking for the informix.rc and other

connectivity files....)

That would be very wrong.



This is actually a very interesting topic.... very little to do with

Informix though :)

Some products like Guardium Data Encryption or IBM Multi-Cloud Data

Encryption which encrypt data and only decrypt it for authorized users have

to handle this same issue to prevent root from impersonating (su) the users

and thereby access the encrypted data. They do that with kernel modules

that somehow (among many other things) track the creation of processes to

understand the real user identity...



Regards and good luck.



On Thu, Apr 19, 2018 at 2:32 PM, RICHARD SPITZ <

richard.spitz@med.uni-muenchen.de> wrote:



> Fernando,

>

> you're spot on! I used gdb to trace what's going on around the opening of

> /proc/self/loginuid, here is the result:

>

> #0 0x00007ffff7bced10 in read () from /lib64/libpthread.so.0

> #1 0x00007ffff6cc8b8a in ?? () from /lib64/libnss_sss.so.2

> #2 0x00007ffff6cc9215 in ?? () from /lib64/libnss_sss.so.2

> #3 0x00007ffff6cc9437 in ?? () from /lib64/libnss_sss.so.2

> #4 0x00007ffff6cca0ec in _nss_sss_getpwuid_r () from

> /lib64/libnss_sss.so.2

> #5 0x00007ffff719b4dc in getpwuid_r@@GLIBC_2.2.5 () from /lib64/libc.so.6

> #6 0x00007ffff71fde98 in __getlogin_r_loginuid () from /lib64/libc.so.6

> #7 0x00007ffff71fdb95 in getlogin () from /lib64/libc.so.6

> #8 0x0000000000465389 in ifx_getlogin ()

> #9 0x00000000004657ab in ggethomepath ()

> #10 0x0000000000464528 in greadenv ()

> #11 0x00000000004647c3 in init_getenv ()

> #12 0x000000000046480f in idx_ggetenv ()

> #13 0x000000000046d50f in _sqdbgsetup ()

> #14 0x00000000004686e3 in ostcb_alloc ()

> #15 0x000000000046871a in CheckOsInit ()

> #16 0x000000000046879c in getoserr ()

> #17 0x000000000040743a in CheckGlobInit ()

> #18 0x00000000004049e7 in sqli_db_open ()

> #19 0x0000000000403b09 in main ()

>

> Just as I was about to start writing my own getlogin() test program, I

> read

> your last post and used your code instead. BTW, I had to add "exit (0)" as

> last line to make it run with SPL "SYSTEM". The first calls to my test SPL

> ran

> very fast (maybe some kind of caching involved), but then I increased the

> debuglevel and could exactly reproduce the delay:

>

> Track before

> Track after

> Time before is: 2018:04:19 13:53:44.448

> Time After is: 2018:04:19 13:53:50.488

> Login is: (null)

>

> Will try to open a support case with SuSE. In the meantime, I'm thinking

> about

> a crude workaround: A little setuid program that reads

> /proc/self/loginuid.

> When that yields "4294967295" (= -1), it will write the result of getuid()

> into that file. When I include that into the shell script just before the

> ESQL/C program is executed, I hope the loginuid will be inherited and my

> problem will be solved for the time being. Will keep you informed.

>

> Thanks again, you were VERY helpful indeed!

>

> Regards, Richard

>

> Thank you very much

>

>

>



>

>

>

>



--

Fernando Nunes

Portugal



http://informix-technology.blogspot.com

My email works... but I don't check it frequently...









* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *



To post a response via email (IIUG members only):



1. Address it to classics@iiug.org

2. Include the bracketed message number in the subject line: [4762]



* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *

Re: ESQL/C Programs take very long time to start u
Posted by: richard.spitz@med.uni-muenchen.de (RICHARD SPITZ) - Thu, 19 Apr 2018 08:32:49 EDT
Fernando,



you're spot on! I used gdb to trace what's going on around the opening of

/proc/self/loginuid, here is the result:



#0 0x00007ffff7bced10 in read () from /lib64/libpthread.so.0

#1 0x00007ffff6cc8b8a in ?? () from /lib64/libnss_sss.so.2

#2 0x00007ffff6cc9215 in ?? () from /lib64/libnss_sss.so.2

#3 0x00007ffff6cc9437 in ?? () from /lib64/libnss_sss.so.2

#4 0x00007ffff6cca0ec in _nss_sss_getpwuid_r () from /lib64/libnss_sss.so.2

#5 0x00007ffff719b4dc in getpwuid_r@@GLIBC_2.2.5 () from /lib64/libc.so.6

#6 0x00007ffff71fde98 in __getlogin_r_loginuid () from /lib64/libc.so.6

#7 0x00007ffff71fdb95 in getlogin () from /lib64/libc.so.6

#8 0x0000000000465389 in ifx_getlogin ()

#9 0x00000000004657ab in ggethomepath ()

#10 0x0000000000464528 in greadenv ()

#11 0x00000000004647c3 in init_getenv ()

#12 0x000000000046480f in idx_ggetenv ()

#13 0x000000000046d50f in _sqdbgsetup ()

#14 0x00000000004686e3 in ostcb_alloc ()

#15 0x000000000046871a in CheckOsInit ()

#16 0x000000000046879c in getoserr ()

#17 0x000000000040743a in CheckGlobInit ()

#18 0x00000000004049e7 in sqli_db_open ()

#19 0x0000000000403b09 in main ()



Just as I was about to start writing my own getlogin() test program, I read

your last post and used your code instead. BTW, I had to add "exit (0)" as

last line to make it run with SPL "SYSTEM". The first calls to my test SPL ran

very fast (maybe some kind of caching involved), but then I increased the

debuglevel and could exactly reproduce the delay:



Track before

Track after

Time before is: 2018:04:19 13:53:44.448

Time After is: 2018:04:19 13:53:50.488

Login is: (null)



Will try to open a support case with SuSE. In the meantime, I'm thinking about

a crude workaround: A little setuid program that reads /proc/self/loginuid.

When that yields "4294967295" (= -1), it will write the result of getuid()

into that file. When I include that into the shell script just before the

ESQL/C program is executed, I hope the loginuid will be inherited and my

problem will be solved for the time being. Will keep you informed.



Thanks again, you were VERY helpful indeed!



Regards, Richard



Thank you very much









* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *



To post a response via email (IIUG members only):



1. Address it to classics@iiug.org

2. Include the bracketed message number in the subject line: [4761]



* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *

Re: ESQL/C Programs take very long time to start u
Posted by: domusonline@gmail.com (Fernando Nunes) - Wed, 18 Apr 2018 18:47:48 EDT
Please replace my previus test case with this one:



#include <unistd.h>

#include <time.h>

#include <stdio.h>

#include <sys/types.h>

#include <math.h>



int main()

{



char buffer[26];



int millisec;



struct tm* tm_info;



struct timeval tv_a, tv_b;



gettimeofday(&tv_b, NULL);



printf("Track before\n");



char *mylogin = getlogin();



printf("Track after\n");



gettimeofday(&tv_a, NULL);



millisec = lrint(tv_b.tv_usec/1000.0); // Round to nearest millisec



if (millisec>=1000) {



//Allow for rounding up to nearest second



millisec -=1000;



tv_b.tv_sec++;



}



tm_info = localtime(&tv_b.tv_sec);



strftime(buffer, 26, "%Y:%m:%d %H:%M:%S", tm_info);



printf("Time before is: %s.%03d\n", buffer, millisec);



millisec = lrint(tv_a.tv_usec/1000.0); // Round to nearest millisec



if (millisec>=1000) {



//Allow for rounding up to nearest second



millisec -=1000;



tv_a.tv_sec++;



}



tm_info = localtime(&tv_a.tv_sec);



strftime(buffer, 26, "%Y:%m:%d %H:%M:%S", tm_info);



printf("Time After is: %s.%03d\n", buffer, millisec);



printf("Login is: %s\n",mylogin);

}



I expect it to work fast on a logged in SHELL and slow on a daemon launched

process.

The problem is probably inside the "getlogin()" POSIX function.

I believe Informix calls getlogin while trying to get the home of the user.



You should try to understand why your system takes time to run getlogin(),

either with your OS provider or with your AD integration software provider

(if different from the OS).

To me it doen't sound good idea to get data from a "-1" user id.



I think if there is no data in /proc/self/logiuid then it should

immediately return NULL (no user associated with a terminal login):



man getlogin:



DESCRIPTION



getlogin() returns a pointer to a string containing the name of

the user logged in on the controlling terminal of the process, or a NULL

pointer if this information cannot be deter‐



mined. The string is statically allocated and might be overwritten

on subsequent calls to this function or to cuserid().



Regards.



On Wed, Apr 18, 2018 at 6:33 PM, Fernando Nunes <domusonline@gmail.com>

wrote:



> On Wed, Apr 18, 2018 at 6:17 PM, RICHARD SPITZ <

> richard.spitz@med.uni-muenchen.de> wrote:

>

> > Fernando,

> >

> > thank you very much for your detailed response. I had written a comment

> in

> > your blog article because that had been the most profound and helpful

> info

> > I

> > had found about configuring IDS with PAM support.

> >

> > > ESQL/C will most probably (that's what I'd like to test/debug) need

> > > to get the user ID *before* trying to connect to IDS. And that's

> > > where it's taking time.

> >

> > Exactly. I think I had written before in this thread that the delay

> occurs

> > before the database connection is established. What's puzzling me is the

> > way

> > ESQL/C does this: First it goes through all the "pain" of reading

> > /proc/self/loginuid and trying to verify that uid via the mechanisms

> > defined

> > in /etc/nsswitch.conf (which MUST fail in case of loginuid "-1", and

> > causes

> > the delay), and then it uses getuid() anyway to continue happily

> > everafter.

> >

> > > That probably means that the LDAP integration software you're

> > > using "hijacks" some internal functions/libraries...

> >

> > Well, I'm using a perfectly standard and well documented mechanism for

> > that:

> > sssd. This is nothing fancy and is integrated into current versions of

> > GLIBC,

> > that is also why PAM is not even needed to connect to IDS as an LDAP

> user.

> >

> > > When you say "interactive" may I assume you opened an SSH/telnet

> > > to the server using the user name of the user? Or have you done an

> > su/sudo?

> >

> > Interactive means that I am in a normal user shell (opened via

> SSH/PuTTY)

> > on

> > the Linux machine Hosting IDS and executing the shell script that is

> > normally

> > invoked by the SPL.

> >

> > > Assuming you did that directly the login process is going through

> > > the authentication and creates the "session context" that makes the

> > > calls run fast

> >

> > The login process sets /proc/self/loginuid for the shell, which is

> > inherited

> > by the program or shell script I'm starting.

> >

> > > This is not being set when a daemon (Informix) changes a process

> > > identity which is what the SYSTEM SPL instruction triggers.

> >

> > Exactly. IDS (oninit) is the daemon, and the PAM module pam_loginuid.so

> is

> > designed to set /proc/self/loginuid. That (pseudo) file is writable only

> > for

> > root, otherwise it would be trivial to write the correct uid to it but

> of

> > course a huge security issue.

> >

> > > 1- Understand why the process takes time after trying to get that

> > > info from the file. Is it calling a daemon for cache, talking to

> > > the LDAP server, etc?. And how can that time be reduced?

> >

> > As written before, the problem is that ESQL/C is trying the UID of "-1"

> > (read

> > from /proc/self/loginuid) to query /etc/passwd and sssd, which MUST be

> > unsuccessful. That UID can not be found in any local cache, that's why a

> > query

> > to the AD servers is done which is of course also unsuccessful. All of

> > this

> > takes time, a query with a correct UID takes only milliseconds.

> >

> > > 2- Check the use of the pam_loginuid in your system.

> >

> > That's what I've been doing all along. Is there a mechanism to make IDS

> > (and

> > other "daemons", like Apache) use that module when invoking subshells or

> > processes?

> >

> > > I suppose the delay is also noticeable when you do the login.

> >

> > No, a valid user login works instantly, no noticeable delay.

> >

> > > 1- Can you change the ESQL/C to CONNECT with a specific user?

> > > Maybe in that case it doesn't need to get the UID?

> >

> > Tried both implicit and explicit connections, no difference in

> behaviour.

> >

> > > 2- You probably can reproduce this by scheduling the process in the

> > > crontab.

> >

> > crond is PAM-enabled and uses pam_loginuid.so, so /proc/self/loginuid is

> > set

> > to the correct UID. I already verified that by scheduling the ESQL/C

> > program

> > in cron.

> >

> > > 3- On many ocassions this weird delays are caused by issues in reverse

> > > lookups (IP to names).

> >

> > No problem there, I can assure you.

> >

> > > I honestly don't know (strace should help) what ESQL/C calls when it

> > > starts....

> >

> > I can send you a complete strace output, but I already mentioned the

> > relevant

> > parts in this thread.

> >

> > > I'm sure Jonathan Leffler would be able to provide some more

> > > info on this, but I haven't seen him here for a while.

> >

> > Honestly, I had hoped that he might read this...

> >

> > > Note that in noway ESQL/C directly accesses the /proc/self/loginuid.

> > > That's a consequence on a system call and your system

> configuration....

> >

> > Sorry, but I think you're wrong. The strace traces prove that the ESQL/C

> > program itself reads /proc/self/loginuid, and that ONLY happens if the

> > program

> > establishes a database connection somewhere later in the program. I

> wrote

> > a

> > dummy ESQL/C program that doesn't open a database connection, and this

> > dummy

> > program doesn't read /proc/self/loginuid and does no user verification

> at

> > all.

> >

> > Regards, Richard

> >

> >

> No. I understand you got that from strace. And I didn't mean that the

> ESQL/C process does not read the file.

> What I mean is that ESQL/C only calls "standard" POSIX functions. And this

> functions in your system (Linux + kernel version + configuration +

> whatever) trigger those operations.

> We would need to understand what call triggers that and if there's a way

> to

> workaround it.

> I thought, apprently wrongly, that it was the call to getuid which I

> confirmed happens on an ESQL/C process. That's why I sent you a test case

> with that call.

> A possible way to try to find that would be to run the ESQL/C program in a

> debugger and set a couple of breakpoints in OS functions close to the

> sequence where it has delays.

> When the program stops and returns control to the debugger try to run a

> "where" and see what's in there. An example with getuid():

>

> castelo@stardust.onlinedomus.net:informix-> gdb ./test.exe

> GNU gdb (GDB) Red Hat Enterprise Linux 7.6.1-100.el7_4.1

> Copyright (C) 2013 Free Software Foundation, Inc.

> License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.

> html

> >

> This is free software: you are free to change and redistribute it.

> There is NO WARRANTY, to the extent permitted by law. Type "show copying"

> and "show warranty" for details.

> This GDB was configured as "x86_64-redhat-linux-gnu".

> For bug reporting instructions, please see:

> <http://www.gnu.org/software/gdb/bugs/>...

> Reading symbols from /tmp/test.exe...(no debugging symbols found)...done.

> (gdb) break getuid

> Function "getuid" not defined.

> Make breakpoint pending on future shared library load? (y or [n]) y

> Breakpoint 1 (getuid) pending.

> (gdb) run

> Starting program: /tmp/./test.exe

> [Thread debugging using libthread_db enabled]

> Using host libthread_db library "/lib64/libthread_db.so.1".

>

> Breakpoint 1, 0x00007ffff640b080 in getuid () from /lib64/libc.so.6

> Missing separate debuginfos, use: debuginfo-install

> glibc-2.17-196.el7_4.2.x86_64 nss-softokn-freebl-3.28.3-8.el7_4.x86_64

> (gdb) where

> #0 0x00007ffff640b080 in getuid () from /lib64/libc.so.6

> #1 0x00007ffff79597e7 in cmInit () from

> /opt/informix/csdk410fc7w1/lib/libifasf.so

> #2 0x00007ffff7950ddf in asfInit () from

> /opt/informix/csdk410fc7w1/lib/libifasf.so

> #3 0x00007ffff795196b in ASF_Call () from

> /opt/informix/csdk410fc7w1/lib/libifasf.so

> #4 0x00007ffff7b99a88 in asf_init () from

> /opt/informix/csdk410fc7w1/lib/esql/libifsql.so

> #5 0x00007ffff7b9ce0d in sqli_connect_open () from

> /opt/informix/csdk410fc7w1/lib/esql/libifsql.so

> #6 0x0000000000400916 in main ()

> (gdb)

>

> In this case the "CONNECT/DATABASE" statement triggers several calls in

> the

> Informix LIBS and then we jump into the getuid().

> You may need to go over several attempts if you can only set the

> breakpoint

> to common functions like "open()"...

>

> Once we find the POSIX function which is causing the sequence that causes

> the delays we may have a shot of reconfigure something to solve it.

> getuid() for example is necessary to get the user id under which we

> run....

>

> Regards.

>

> >

> >

>



>

> >

> >

> >

> >

>

> --

> Fernando Nunes

> Portugal

>

> http://informix-technology.blogspot.com

> My email works... but I don't check it frequently...

>

>

>



>

>

>

>



--

Fernando Nunes

Portugal



http://informix-technology.blogspot.com

My email works... but I don't check it frequently...









* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *



To post a response via email (IIUG members only):



1. Address it to classics@iiug.org

2. Include the bracketed message number in the subject line: [4760]



* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *

Re: ESQL/C Programs take very long time to start u
Posted by: david@smooth1.co.uk (david@smooth1.co.uk) - Wed, 18 Apr 2018 14:52:51 EDT
Use dtrace to get the stack for open() calls, optionally when the filename is

the loginuid file.



ALso get the stack for getuid calls.



https://www.joyent.com/blog/bruning-questions-debugging



Regards,

David.



> On 18 April 2018 at 17:33 Fernando Nunes <domusonline@gmail.com> wrote:

>

>

> On Wed, Apr 18, 2018 at 6:17 PM, RICHARD SPITZ <

> richard.spitz@med.uni-muenchen.de> wrote:

>

> > Fernando,

> >

> > thank you very much for your detailed response. I had written a comment in

> > your blog article because that had been the most profound and helpful info

> > I

> > had found about configuring IDS with PAM support.

> >

> > > ESQL/C will most probably (that's what I'd like to test/debug) need

> > > to get the user ID *before* trying to connect to IDS. And that's

> > > where it's taking time.

> >

> > Exactly. I think I had written before in this thread that the delay occurs

> > before the database connection is established. What's puzzling me is the

> > way

> > ESQL/C does this: First it goes through all the "pain" of reading

> > /proc/self/loginuid and trying to verify that uid via the mechanisms

> > defined

> > in /etc/nsswitch.conf (which MUST fail in case of loginuid "-1", and

> > causes

> > the delay), and then it uses getuid() anyway to continue happily

> > everafter.

> >

> > > That probably means that the LDAP integration software you're

> > > using "hijacks" some internal functions/libraries...

> >

> > Well, I'm using a perfectly standard and well documented mechanism for

> > that:

> > sssd. This is nothing fancy and is integrated into current versions of

> > GLIBC,

> > that is also why PAM is not even needed to connect to IDS as an LDAP user.

> >

> > > When you say "interactive" may I assume you opened an SSH/telnet

> > > to the server using the user name of the user? Or have you done an

> > su/sudo?

> >

> > Interactive means that I am in a normal user shell (opened via SSH/PuTTY)

> > on

> > the Linux machine Hosting IDS and executing the shell script that is

> > normally

> > invoked by the SPL.

> >

> > > Assuming you did that directly the login process is going through

> > > the authentication and creates the "session context" that makes the

> > > calls run fast

> >

> > The login process sets /proc/self/loginuid for the shell, which is

> > inherited

> > by the program or shell script I'm starting.

> >

> > > This is not being set when a daemon (Informix) changes a process

> > > identity which is what the SYSTEM SPL instruction triggers.

> >

> > Exactly. IDS (oninit) is the daemon, and the PAM module pam_loginuid.so is

> > designed to set /proc/self/loginuid. That (pseudo) file is writable only

> > for

> > root, otherwise it would be trivial to write the correct uid to it but of

> > course a huge security issue.

> >

> > > 1- Understand why the process takes time after trying to get that

> > > info from the file. Is it calling a daemon for cache, talking to

> > > the LDAP server, etc?. And how can that time be reduced?

> >

> > As written before, the problem is that ESQL/C is trying the UID of "-1"

> > (read

> > from /proc/self/loginuid) to query /etc/passwd and sssd, which MUST be

> > unsuccessful. That UID can not be found in any local cache, that's why a

> > query

> > to the AD servers is done which is of course also unsuccessful. All of

> > this

> > takes time, a query with a correct UID takes only milliseconds.

> >

> > > 2- Check the use of the pam_loginuid in your system.

> >

> > That's what I've been doing all along. Is there a mechanism to make IDS

> > (and

> > other "daemons", like Apache) use that module when invoking subshells or

> > processes?

> >

> > > I suppose the delay is also noticeable when you do the login.

> >

> > No, a valid user login works instantly, no noticeable delay.

> >

> > > 1- Can you change the ESQL/C to CONNECT with a specific user?

> > > Maybe in that case it doesn't need to get the UID?

> >

> > Tried both implicit and explicit connections, no difference in behaviour.

> >

> > > 2- You probably can reproduce this by scheduling the process in the

> > > crontab.

> >

> > crond is PAM-enabled and uses pam_loginuid.so, so /proc/self/loginuid is

> > set

> > to the correct UID. I already verified that by scheduling the ESQL/C

> > program

> > in cron.

> >

> > > 3- On many ocassions this weird delays are caused by issues in reverse

> > > lookups (IP to names).

> >

> > No problem there, I can assure you.

> >

> > > I honestly don't know (strace should help) what ESQL/C calls when it

> > > starts....

> >

> > I can send you a complete strace output, but I already mentioned the

> > relevant

> > parts in this thread.

> >

> > > I'm sure Jonathan Leffler would be able to provide some more

> > > info on this, but I haven't seen him here for a while.

> >

> > Honestly, I had hoped that he might read this...

> >

> > > Note that in noway ESQL/C directly accesses the /proc/self/loginuid.

> > > That's a consequence on a system call and your system configuration....

> >

> > Sorry, but I think you're wrong. The strace traces prove that the ESQL/C

> > program itself reads /proc/self/loginuid, and that ONLY happens if the

> > program

> > establishes a database connection somewhere later in the program. I wrote

> > a

> > dummy ESQL/C program that doesn't open a database connection, and this

> > dummy

> > program doesn't read /proc/self/loginuid and does no user verification at

> > all.

> >

> > Regards, Richard

> >

> >

> No. I understand you got that from strace. And I didn't mean that the

> ESQL/C process does not read the file.

> What I mean is that ESQL/C only calls "standard" POSIX functions. And this

> functions in your system (Linux + kernel version + configuration +

> whatever) trigger those operations.

> We would need to understand what call triggers that and if there's a way to

> workaround it.

> I thought, apprently wrongly, that it was the call to getuid which I

> confirmed happens on an ESQL/C process. That's why I sent you a test case

> with that call.

> A possible way to try to find that would be to run the ESQL/C program in a

> debugger and set a couple of breakpoints in OS functions close to the

> sequence where it has delays.

> When the program stops and returns control to the debugger try to run a

> "where" and see what's in there. An example with getuid():

>

> castelo@stardust.onlinedomus.net:informix-> gdb ./test.exe

> GNU gdb (GDB) Red Hat Enterprise Linux 7.6.1-100.el7_4.1

> Copyright (C) 2013 Free Software Foundation, Inc.

> License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html

> >

> This is free software: you are free to change and redistribute it.

> There is NO WARRANTY, to the extent permitted by law. Type "show copying"

> and "show warranty" for details.

> This GDB was configured as "x86_64-redhat-linux-gnu".

> For bug reporting instructions, please see:

> <http://www.gnu.org/software/gdb/bugs/>...

> Reading symbols from /tmp/test.exe...(no debugging symbols found)...done.

> (gdb) break getuid

> Function "getuid" not defined.

> Make breakpoint pending on future shared library load? (y or [n]) y

> Breakpoint 1 (getuid) pending.

> (gdb) run

> Starting program: /tmp/./test.exe

> [Thread debugging using libthread_db enabled]

> Using host libthread_db library "/lib64/libthread_db.so.1".

>

> Breakpoint 1, 0x00007ffff640b080 in getuid () from /lib64/libc.so.6

> Missing separate debuginfos, use: debuginfo-install

> glibc-2.17-196.el7_4.2.x86_64 nss-softokn-freebl-3.28.3-8.el7_4.x86_64

> (gdb) where

> #0 0x00007ffff640b080 in getuid () from /lib64/libc.so.6

> #1 0x00007ffff79597e7 in cmInit () from

> /opt/informix/csdk410fc7w1/lib/libifasf.so

> #2 0x00007ffff7950ddf in asfInit () from

> /opt/informix/csdk410fc7w1/lib/libifasf.so

> #3 0x00007ffff795196b in ASF_Call () from

> /opt/informix/csdk410fc7w1/lib/libifasf.so

> #4 0x00007ffff7b99a88 in asf_init () from

> /opt/informix/csdk410fc7w1/lib/esql/libifsql.so

> #5 0x00007ffff7b9ce0d in sqli_connect_open () from

> /opt/informix/csdk410fc7w1/lib/esql/libifsql.so

> #6 0x0000000000400916 in main ()

> (gdb)

>

> In this case the "CONNECT/DATABASE" statement triggers several calls in the

> Informix LIBS and then we jump into the getuid().

> You may need to go over several attempts if you can only set the breakpoint

> to common functions like "open()"...

>

> Once we find the POSIX function which is causing the sequence that causes

> the delays we may have a shot of reconfigure something to solve it.

> getuid() for example is necessary to get the user id under which we run....

>

> Regards.

>

> >

> >

>



> >

> >

> >

> >

>

> --

> Fernando Nunes

> Portugal

>

> http://informix-technology.blogspot.com

> My email works... but I don't check it frequently...

>

>

>



>

>









* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *



To post a response via email (IIUG members only):



1. Address it to classics@iiug.org

2. Include the bracketed message number in the subject line: [4759]



* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *

Re: RE: ESQL/C Programs take very long time to sta
Posted by: domusonline@gmail.com (Fernando Nunes) - Wed, 18 Apr 2018 12:39:21 EDT
Yes. So that clears out any Informix authentication issues or configuration

details (you already mentioned that).

The problem clearly is that when a daemon starts a process nothing in the

system configuration forces the entry in the /proc/self/loginuid. However

when a certain (to be determined) POSIX function is called by the process

the system seems to be "dumb enough" to follow the search process on the

various "stacks" using an invalid (-1/NULL) user id.... ah... the wonders

of free and open systems :)



Regards.



On Wed, Apr 18, 2018 at 6:20 PM, RICHARD SPITZ <

richard.spitz@med.uni-muenchen.de> wrote:



> To clarify:

>

> The common denominator in both questions (here and on stackoverflow) is an

> ESQL/C program launched by a "daemon". Here the daemon is IDS launching

> the

> program via the SPL "SYSTEM" command, there the daemon is Apache launching

> (another) ESQL/C program via CGI.

>

>

>



>

>

>

>



--

Fernando Nunes

Portugal



http://informix-technology.blogspot.com

My email works... but I don't check it frequently...









* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *



To post a response via email (IIUG members only):



1. Address it to classics@iiug.org

2. Include the bracketed message number in the subject line: [4758]



* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *

Re: ESQL/C Programs take very long time to start u
Posted by: domusonline@gmail.com (Fernando Nunes) - Wed, 18 Apr 2018 12:33:53 EDT
On Wed, Apr 18, 2018 at 6:17 PM, RICHARD SPITZ <

richard.spitz@med.uni-muenchen.de> wrote:



> Fernando,

>

> thank you very much for your detailed response. I had written a comment in

> your blog article because that had been the most profound and helpful info

> I

> had found about configuring IDS with PAM support.

>

> > ESQL/C will most probably (that's what I'd like to test/debug) need

> > to get the user ID *before* trying to connect to IDS. And that's

> > where it's taking time.

>

> Exactly. I think I had written before in this thread that the delay occurs

> before the database connection is established. What's puzzling me is the

> way

> ESQL/C does this: First it goes through all the "pain" of reading

> /proc/self/loginuid and trying to verify that uid via the mechanisms

> defined

> in /etc/nsswitch.conf (which MUST fail in case of loginuid "-1", and

> causes

> the delay), and then it uses getuid() anyway to continue happily

> everafter.

>

> > That probably means that the LDAP integration software you're

> > using "hijacks" some internal functions/libraries...

>

> Well, I'm using a perfectly standard and well documented mechanism for

> that:

> sssd. This is nothing fancy and is integrated into current versions of

> GLIBC,

> that is also why PAM is not even needed to connect to IDS as an LDAP user.

>

> > When you say "interactive" may I assume you opened an SSH/telnet

> > to the server using the user name of the user? Or have you done an

> su/sudo?

>

> Interactive means that I am in a normal user shell (opened via SSH/PuTTY)

> on

> the Linux machine Hosting IDS and executing the shell script that is

> normally

> invoked by the SPL.

>

> > Assuming you did that directly the login process is going through

> > the authentication and creates the "session context" that makes the

> > calls run fast

>

> The login process sets /proc/self/loginuid for the shell, which is

> inherited

> by the program or shell script I'm starting.

>

> > This is not being set when a daemon (Informix) changes a process

> > identity which is what the SYSTEM SPL instruction triggers.

>

> Exactly. IDS (oninit) is the daemon, and the PAM module pam_loginuid.so is

> designed to set /proc/self/loginuid. That (pseudo) file is writable only

> for

> root, otherwise it would be trivial to write the correct uid to it but of

> course a huge security issue.

>

> > 1- Understand why the process takes time after trying to get that

> > info from the file. Is it calling a daemon for cache, talking to

> > the LDAP server, etc?. And how can that time be reduced?

>

> As written before, the problem is that ESQL/C is trying the UID of "-1"

> (read

> from /proc/self/loginuid) to query /etc/passwd and sssd, which MUST be

> unsuccessful. That UID can not be found in any local cache, that's why a

> query

> to the AD servers is done which is of course also unsuccessful. All of

> this

> takes time, a query with a correct UID takes only milliseconds.

>

> > 2- Check the use of the pam_loginuid in your system.

>

> That's what I've been doing all along. Is there a mechanism to make IDS

> (and

> other "daemons", like Apache) use that module when invoking subshells or

> processes?

>

> > I suppose the delay is also noticeable when you do the login.

>

> No, a valid user login works instantly, no noticeable delay.

>

> > 1- Can you change the ESQL/C to CONNECT with a specific user?

> > Maybe in that case it doesn't need to get the UID?

>

> Tried both implicit and explicit connections, no difference in behaviour.

>

> > 2- You probably can reproduce this by scheduling the process in the

> > crontab.

>

> crond is PAM-enabled and uses pam_loginuid.so, so /proc/self/loginuid is

> set

> to the correct UID. I already verified that by scheduling the ESQL/C

> program

> in cron.

>

> > 3- On many ocassions this weird delays are caused by issues in reverse

> > lookups (IP to names).

>

> No problem there, I can assure you.

>

> > I honestly don't know (strace should help) what ESQL/C calls when it

> > starts....

>

> I can send you a complete strace output, but I already mentioned the

> relevant

> parts in this thread.

>

> > I'm sure Jonathan Leffler would be able to provide some more

> > info on this, but I haven't seen him here for a while.

>

> Honestly, I had hoped that he might read this...

>

> > Note that in noway ESQL/C directly accesses the /proc/self/loginuid.

> > That's a consequence on a system call and your system configuration....

>

> Sorry, but I think you're wrong. The strace traces prove that the ESQL/C

> program itself reads /proc/self/loginuid, and that ONLY happens if the

> program

> establishes a database connection somewhere later in the program. I wrote

> a

> dummy ESQL/C program that doesn't open a database connection, and this

> dummy

> program doesn't read /proc/self/loginuid and does no user verification at

> all.

>

> Regards, Richard

>

>

No. I understand you got that from strace. And I didn't mean that the

ESQL/C process does not read the file.

What I mean is that ESQL/C only calls "standard" POSIX functions. And this

functions in your system (Linux + kernel version + configuration +

whatever) trigger those operations.

We would need to understand what call triggers that and if there's a way to

workaround it.

I thought, apprently wrongly, that it was the call to getuid which I

confirmed happens on an ESQL/C process. That's why I sent you a test case

with that call.

A possible way to try to find that would be to run the ESQL/C program in a

debugger and set a couple of breakpoints in OS functions close to the

sequence where it has delays.

When the program stops and returns control to the debugger try to run a

"where" and see what's in there. An example with getuid():



castelo@stardust.onlinedomus.net:informix-> gdb ./test.exe

GNU gdb (GDB) Red Hat Enterprise Linux 7.6.1-100.el7_4.1

Copyright (C) 2013 Free Software Foundation, Inc.

License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html

>

This is free software: you are free to change and redistribute it.

There is NO WARRANTY, to the extent permitted by law. Type "show copying"

and "show warranty" for details.

This GDB was configured as "x86_64-redhat-linux-gnu".

For bug reporting instructions, please see:

<http://www.gnu.org/software/gdb/bugs/>...

Reading symbols from /tmp/test.exe...(no debugging symbols found)...done.

(gdb) break getuid

Function "getuid" not defined.

Make breakpoint pending on future shared library load? (y or [n]) y

Breakpoint 1 (getuid) pending.

(gdb) run

Starting program: /tmp/./test.exe

[Thread debugging using libthread_db enabled]

Using host libthread_db library "/lib64/libthread_db.so.1".



Breakpoint 1, 0x00007ffff640b080 in getuid () from /lib64/libc.so.6

Missing separate debuginfos, use: debuginfo-install

glibc-2.17-196.el7_4.2.x86_64 nss-softokn-freebl-3.28.3-8.el7_4.x86_64

(gdb) where

#0 0x00007ffff640b080 in getuid () from /lib64/libc.so.6

#1 0x00007ffff79597e7 in cmInit () from

/opt/informix/csdk410fc7w1/lib/libifasf.so

#2 0x00007ffff7950ddf in asfInit () from

/opt/informix/csdk410fc7w1/lib/libifasf.so

#3 0x00007ffff795196b in ASF_Call () from

/opt/informix/csdk410fc7w1/lib/libifasf.so

#4 0x00007ffff7b99a88 in asf_init () from

/opt/informix/csdk410fc7w1/lib/esql/libifsql.so

#5 0x00007ffff7b9ce0d in sqli_connect_open () from

/opt/informix/csdk410fc7w1/lib/esql/libifsql.so

#6 0x0000000000400916 in main ()

(gdb)



In this case the "CONNECT/DATABASE" statement triggers several calls in the

Informix LIBS and then we jump into the getuid().

You may need to go over several attempts if you can only set the breakpoint

to common functions like "open()"...



Once we find the POSIX function which is causing the sequence that causes

the delays we may have a shot of reconfigure something to solve it.

getuid() for example is necessary to get the user id under which we run....



Regards.



>

>



>

>

>

>



--

Fernando Nunes

Portugal



http://informix-technology.blogspot.com

My email works... but I don't check it frequently...









* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *



To post a response via email (IIUG members only):



1. Address it to classics@iiug.org

2. Include the bracketed message number in the subject line: [4757]



* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *

Re: RE: ESQL/C Programs take very long time to sta
Posted by: richard.spitz@med.uni-muenchen.de (RICHARD SPITZ) - Wed, 18 Apr 2018 12:20:51 EDT
To clarify:



The common denominator in both questions (here and on stackoverflow) is an

ESQL/C program launched by a "daemon". Here the daemon is IDS launching the

program via the SPL "SYSTEM" command, there the daemon is Apache launching

(another) ESQL/C program via CGI.









* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *



To post a response via email (IIUG members only):



1. Address it to classics@iiug.org

2. Include the bracketed message number in the subject line: [4756]



* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *

Re: ESQL/C Programs take very long time to start u
Posted by: richard.spitz@med.uni-muenchen.de (RICHARD SPITZ) - Wed, 18 Apr 2018 12:17:11 EDT
Fernando,



thank you very much for your detailed response. I had written a comment in

your blog article because that had been the most profound and helpful info I

had found about configuring IDS with PAM support.



> ESQL/C will most probably (that's what I'd like to test/debug) need

> to get the user ID *before* trying to connect to IDS. And that's

> where it's taking time.



Exactly. I think I had written before in this thread that the delay occurs

before the database connection is established. What's puzzling me is the way

ESQL/C does this: First it goes through all the "pain" of reading

/proc/self/loginuid and trying to verify that uid via the mechanisms defined

in /etc/nsswitch.conf (which MUST fail in case of loginuid "-1", and causes

the delay), and then it uses getuid() anyway to continue happily everafter.



> That probably means that the LDAP integration software you're

> using "hijacks" some internal functions/libraries...



Well, I'm using a perfectly standard and well documented mechanism for that:

sssd. This is nothing fancy and is integrated into current versions of GLIBC,

that is also why PAM is not even needed to connect to IDS as an LDAP user.



> When you say "interactive" may I assume you opened an SSH/telnet

> to the server using the user name of the user? Or have you done an su/sudo?



Interactive means that I am in a normal user shell (opened via SSH/PuTTY) on

the Linux machine Hosting IDS and executing the shell script that is normally

invoked by the SPL.



> Assuming you did that directly the login process is going through

> the authentication and creates the "session context" that makes the

> calls run fast



The login process sets /proc/self/loginuid for the shell, which is inherited

by the program or shell script I'm starting.



> This is not being set when a daemon (Informix) changes a process

> identity which is what the SYSTEM SPL instruction triggers.



Exactly. IDS (oninit) is the daemon, and the PAM module pam_loginuid.so is

designed to set /proc/self/loginuid. That (pseudo) file is writable only for

root, otherwise it would be trivial to write the correct uid to it but of

course a huge security issue.



> 1- Understand why the process takes time after trying to get that

> info from the file. Is it calling a daemon for cache, talking to

> the LDAP server, etc?. And how can that time be reduced?



As written before, the problem is that ESQL/C is trying the UID of "-1" (read

from /proc/self/loginuid) to query /etc/passwd and sssd, which MUST be

unsuccessful. That UID can not be found in any local cache, that's why a query

to the AD servers is done which is of course also unsuccessful. All of this

takes time, a query with a correct UID takes only milliseconds.



> 2- Check the use of the pam_loginuid in your system.



That's what I've been doing all along. Is there a mechanism to make IDS (and

other "daemons", like Apache) use that module when invoking subshells or

processes?



> I suppose the delay is also noticeable when you do the login.



No, a valid user login works instantly, no noticeable delay.



> 1- Can you change the ESQL/C to CONNECT with a specific user?

> Maybe in that case it doesn't need to get the UID?



Tried both implicit and explicit connections, no difference in behaviour.



> 2- You probably can reproduce this by scheduling the process in the

> crontab.



crond is PAM-enabled and uses pam_loginuid.so, so /proc/self/loginuid is set

to the correct UID. I already verified that by scheduling the ESQL/C program

in cron.



> 3- On many ocassions this weird delays are caused by issues in reverse

> lookups (IP to names).



No problem there, I can assure you.



> I honestly don't know (strace should help) what ESQL/C calls when it

> starts....



I can send you a complete strace output, but I already mentioned the relevant

parts in this thread.



> I'm sure Jonathan Leffler would be able to provide some more

> info on this, but I haven't seen him here for a while.



Honestly, I had hoped that he might read this...



> Note that in noway ESQL/C directly accesses the /proc/self/loginuid.

> That's a consequence on a system call and your system configuration....



Sorry, but I think you're wrong. The strace traces prove that the ESQL/C

program itself reads /proc/self/loginuid, and that ONLY happens if the program

establishes a database connection somewhere later in the program. I wrote a

dummy ESQL/C program that doesn't open a database connection, and this dummy

program doesn't read /proc/self/loginuid and does no user verification at all.



Regards, Richard









* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *



To post a response via email (IIUG members only):



1. Address it to classics@iiug.org

2. Include the bracketed message number in the subject line: [4755]



* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *

Re: RE: ESQL/C Programs take very long time to sta
Posted by: domusonline@gmail.com (Fernando Nunes) - Wed, 18 Apr 2018 11:50:26 EDT
Considering this:



https://stackoverflow.com/questions/49877098/apache-cgi-loginuid



Can you clarify if the process is being launched by Informix server, Apache

server or both?



Thanks.



On Wed, Apr 18, 2018 at 5:29 PM, RICHARD SPITZ <

richard.spitz@med.uni-muenchen.de> wrote:



> The SYSTEM command within SPL calls a shell script which in turn invokes

> strace with the ESQL/C program. I tried different shells within the

> script:

> bash (default), ksh and csh, with no difference whatsoever.

>

>

>



>

>

>

>



--

Fernando Nunes

Portugal



http://informix-technology.blogspot.com

My email works... but I don't check it frequently...









* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *



To post a response via email (IIUG members only):



1. Address it to classics@iiug.org

2. Include the bracketed message number in the subject line: [4754]



* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *

Considering this:



https://stackoverflow.com/questions/49877098/apache-cgi-loginuid



Can you clarify if the process is being launched by Informix server, Apache

server or both?



Thanks.



On Wed, Apr 18, 2018 at 5:29 PM, RICHARD SPITZ <

richard.spitz@med.uni-muenchen.de> wrote:



> The SYSTEM command within SPL calls a shell script which in turn invokes

> strace with the ESQL/C program. I tried different shells within the

> script:

> bash (default), ksh and csh, with no difference whatsoever.

>

>

>



>

>

>

>



--

Fernando Nunes

Portugal



http://informix-technology.blogspot.com

My email works... but I don't check it frequently...









* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *



To post a response via email (IIUG members only):



1. Address it to classics@iiug.org

2. Include the bracketed message number in the subject line: [4754]



* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *

 
Subscribe to this feed
You can subscribe to this RSS feed in a number of ways, including the following:

Drag the orange RSS button into your News Reader

Drag the URL of the RSS feed into your News Reader

Cut and paste the URL of the RSS feed into your News Readerv