Re: ESQL/C program called from SPL with SYSTEM com
When running from ESQL/C directly from the command line is /proc/self/loginuid
set?
I would not say this is a PAM issue but instead it is that when oninit is
called the caller has not set the login id.
Quick workaround: From SPL call a script and have a wrapper script set the
/proc/self/loginuid value before calling the ESQL/C program.
Look like all the PAM module does is write to /proc/self/loginuid
https://fossies.org/dox/Linux-PAM-1.3.0/pam__loginuid_8c_source.html
The big question is what id would you set as the login id?
The user running the SPL has not logged into the OS, in fact oninit may not
have been lauched from a session with 'logged in' to the OS.
Should the SPL be audited as root/informix or the user who ran the SPL?
Informix can have internal users
https://www.ibm.com/support/knowledgecenter/en/SSGU8G_12.1.0/com.ibm.sec.doc/ids
_am_045.htm which "users that do not authenticate on the OS of the host
computer".
"Internally authenticated users can connect even if the user cannot be
identified by the OS.", how should that be handled?
It is hard for Informix to handle all cases!
Regards,
David.
> On 17 April 2018 at 09:42 RICHARD SPITZ <richard.spitz@med.uni-muenchen.de>
wrote:
>
>
> Hi Informixers,
>
> please bear with me if the following sounds a little confusing. I am
> thoroughly confused myself.
>
> We're running IDS 12.10.FC8W1WE on SLES 12 SP1. The system is configured to
> authenticate users via local files (/etc/passwd) and sssd against an Active
> Directory domain.
>
> ESQL/C programs run fine when called from the command line and via crond.
> However, the same programs experience delays starting up when called in a
> stored procedure via the SYSTEM command.
>
> Via strace, I found out that ESQL/C programs read /proc/self/loginuid to find
> out the UID they are running under. When called from SPL, this yields
> "4294967295", which is equivalent to "-1". Following the settings in
> nsswitch.conf, first the local passwd file is queried and then AD via sssd,
> with both queries being unsuccessful, of course. The AD query with UID
> "4294967295" causes the delay of 6-8 seconds on average, but sometimes up to
> one minute.
>
> After that delay, getuid() is called which results in the correct UID of the
> user invoking the stored procedure, and the program continues successfully.
>
> I assume this might be a PAM issue, since there is a PAM module
> pam_loginuid.so that is invoked e.g. by crond to set the correct loginuid for
> a program called via the cron mechanism. Any idea how to make IDS use
> pam_loginuid.so when calling a program via SPL?
>
> This is my sqlhosts:
>
> xxserver onipcshm anaxxx.srv.mxx.xxx.de opserver_shm
> xxserver_tcp onsoctcp anaxxx.srv.mxx.xxx.de sqlexec
> s=4,pam_serv=(pam_informix),pamauth=(password)
> xxserver_classic onsoctcp anaxxx.srv.mxx.xxx.de 22222>
> And the pam_informix file in /etc/pam.d:
> auth sufficient pam_rhosts.so
> auth sufficient pam_unix.so
> auth sufficient pam_sss.so use_first_pass
> account required pam_unix.so
>
> Please note that the described behavior occurs no matter which connection the
> invoking user is using; the ESQL/C program will always use the local shared
> memory connection when called via SPL, but the DB connection is established
> after the described delay.
>
> BTW: getpwnam() works with both /etc/passwd and sssd, so the explicit PAM
> configuration is most likely not even necessary.
>
> Regards, Richard
>
>
>
*******************************************************************************
> Forum Note: Use "Reply" to post a response in the discussion forum.
>
On Wed, Apr 18, 2018 at 3:24 PM, david@smooth1.co.uk <david@smooth1.co.uk>
wrote:
> When running from ESQL/C directly from the command line is
> /proc/self/loginuid
> set?
>
> I would not say this is a PAM issue but instead it is that when oninit is
> called the caller has not set the login id.
>
The /proc/self/loginuid will be different for each process. So the relevant
process here is not "oninit", but the process launched by SYSTEM SPL (the
ESQL/C process)
>
> Quick workaround: From SPL call a script and have a wrapper script set the
> /proc/self/loginuid value before calling the ESQL/C program.
>
I doubt that the file can be written by a non-privilege process. Apparently
this is set for audit purposes so it seems a sensitive topic. However there
may be some options to allow it...
>
> Look like all the PAM module does is write to /proc/self/loginuid
>
> https://fossies.org/dox/Linux-PAM-1.3.0/pam__loginuid_8c_source.html
>
> The big question is what id would you set as the login id?
>
> The user running the SPL has not logged into the OS, in fact oninit may
> not
> have been lauched from a session with 'logged in' to the OS.
>
>
Informix forks a new process and then changes that process uid to the
database user.
This is one of the reasons why we need some oninit(s) to be running as root
and also why the user id must be known to the system or must be mapped to a
user that is known to the system.
So if what you're proposing is changing the file, that would be to set the
database user id which may raise some security concerns.
> Should the SPL be audited as root/informix or the user who ran the SPL?
>
> Informix can have internal users
> https://www.ibm.com/support/knowledgecenter/en/SSGU8G_12.
> 1.0/com.ibm.sec.doc/ids_am_045.htm
> which "users that do not authenticate on the OS of the host computer".
>
> "Internally authenticated users can connect even if the user cannot be
> identified by the OS.", how should that be handled?
>
>
The "internal" users must be mapped.... mapped users was also introduced.
There are several engine actions that require a "real user id":
- SPL SYSTEM
- SPL DEBUG
- SET EXPLAIN to a file
- ?...
It is hard for Informix to handle all cases!
>
The point here is not if it's hard, but to identify exactly what's taken
time and why. I'd suggest the OP to create a simple C program:
================================================================================
==
#include <time.h>
#include <stdio.h>
#include <sys/types.h>
#include <math.h>
int main()
{
uid_t myuid;
char buffer[26];
int millisec;
struct tm* tm_info;
struct timeval tv_a, tv_b;
gettimeofday(&tv_b, NULL);
myuid=getuid();
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\\
", 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\\
", buffer, millisec);
printf("UID is: %d\\
",myuid);
}
================================================================================
==
Save it to test_guid.c and compile it with:
gcc -o test_guid test_guid.c -l m
Test it (logged in) with:
./test_guid
Time Before is: 2018:04:18 15:37:12.858
Time After is: 2018:04:18 15:37:12.858
UID is: 200
Now, create a SPL that calls the same program, or a script that calls the
same program and redirects the output to "/tmp/spl_debug.txt" for example.
Check the time it took.
If it takes time as the ESQL/C we've confirmed this is not related to
Informix.
ESQL does call getuid().
Regards
Regards,
> David.
>
> > On 17 April 2018 at 09:42 RICHARD SPITZ <richard.spitz@med.uni-
> muenchen.de>
> wrote:
> >
> >
> > Hi Informixers,
> >
> > please bear with me if the following sounds a little confusing. I am
> > thoroughly confused myself.
> >
> > We're running IDS 12.10.FC8W1WE on SLES 12 SP1. The system is configured
> to
> > authenticate users via local files (/etc/passwd) and sssd against an
> Active
> > Directory domain.
> >
> > ESQL/C programs run fine when called from the command line and via
> crond.
> > However, the same programs experience delays starting up when called in
> a
> > stored procedure via the SYSTEM command.
> >
> > Via strace, I found out that ESQL/C programs read /proc/self/loginuid to
> find
> > out the UID they are running under. When called from SPL, this yields
> > "4294967295", which is equivalent to "-1". Following the settings in
> > nsswitch.conf, first the local passwd file is queried and then AD via
> sssd,
> > with both queries being unsuccessful, of course. The AD query with UID
> > "4294967295" causes the delay of 6-8 seconds on average, but sometimes
> up to
> > one minute.
> >
> > After that delay, getuid() is called which results in the correct UID of
> the
> > user invoking the stored procedure, and the program continues
> successfully.
> >
> > I assume this might be a PAM issue, since there is a PAM module
> > pam_loginuid.so that is invoked e.g. by crond to set the correct
> loginuid
> for
> > a program called via the cron mechanism. Any idea how to make IDS use
> > pam_loginuid.so when calling a program via SPL?
> >
> > This is my sqlhosts:
> >
> > xxserver onipcshm anaxxx.srv.mxx.xxx.de opserver_shm
> > xxserver_tcp onsoctcp anaxxx.srv.mxx.xxx.de sqlexec
> > s=4,pam_serv=(pam_informix),pamauth=(password)
> > xxserver_classic onsoctcp anaxxx.srv.mxx.xxx.de 22222> >
> > And the pam_informix file in /etc/pam.d:
> > auth sufficient pam_rhosts.so
> > auth sufficient pam_unix.so
> > auth sufficient pam_sss.so use_first_pass
> > account required pam_unix.so
> >
> > Please note that the described behavior occurs no matter which
> connection
> the
> > invoking user is using; the ESQL/C program will always use the local
> shared
> > memory connection when called via SPL, but the DB connection is
> established
> > after the described delay.
> >
> > BTW: getpwnam() works with both /etc/passwd and sssd, so the explicit
> PAM
> > configuration is most likely not even necessary.
> >
> > Regards, Richard
> >
> >
> >
>
*******************************************************************************
>
> > Forum Note: Use @
Fernando, thanks for your very valid explanations and your test program. It indeed yields identical results when run from an interactive login shell and from a stored procedure, but in the other thread in "Classics" you already mentioned that getuid() is tested but that is not what causes the issue. Regards, Richard