I have a NATURAL batch shell script with the user sticky bit permission set. This allows my users to execute NATURAL via the script and inherit the permissions of the shell script owner in order to write to a specific set of protected files. Otherwise, the users don’t have access.
This worked great until I upgraded from ADABAS 3.3.2.02 to 3.3.3.01. Now the same NATURAL program receives a NAT3148. I have been unable to figure out what’s wrong. Any suggestions would be welcomed.
Thanks,
Robert
I guess this has nothing to do with the sticky bit permissions. You receive a NAT3148. It seems to me that you got a communcation problem between ADABAS and NATURAL. Natural was called properly.
In case of a Problem with for workfile-permissions, you would get a NAT1500…
Here’s what I have found out from support. Seems that starting with ADABAS 3.3.3, the standard ADALNK libraries don’t support sticky bit permissions and block access to ADABAS.
There is an ADALNK library for backwards compatability named libadalnknc.sl that does support sticky bit permissions. I correct my problem, in the shell script with sticky bit permissions, just prior to executing NATURAL I change ADALNK to point to the libadalnknc.sl.
So far, no one can explain why SAG went to the trouble to block sticky bit permissions in the ADALNK libraries. And of course, none of this is documented.
Hi,
please check the following:
The new adalnk (ADA331/09 and above) needs shared libs from $SAG/common /lib. He finds this libs using LD_LIBRARY_PATH. This path will not be evaluated as far a s-bit has been set.
*
To have access to Adabas with ADA331/09 and above:
Set the environment variable ADALNK (set in adaenv) to libadalnknc.so.
The libadalnknc.so is the “old” adalnk (no multithreading ) this one doesn’t use XTS. Therefore doesn’t need access to $SAG/common/lib…
Where is this documented? I couldn’t find it and support didn’t mention it.
I’m sorry that this point isn’t as clear documented as it could be.
In one of the next adabas 5 patch levels the behavior with the
libadalnk in conjunction with the use of a s-bit will be documented.
:oops:
Why has support for the s-bit been dropped? Why does ADABAS even care? Was there a technical reason? I can’t see it.
On UNIX, it’s common practice to assign permissions to applications, not to users to restrict access to UNIX resources. With SAG’s decision to block s-bit permissions, SAG is forcing UNIX customers into difficult position.
If SAG is going to effectively take away UNIX functionality that has been available long before SAG had products on UNIX, does SAG have an alternative UNIX solution?
So far, this has only affected my NATURAL to ADABAS and NATURAL to NET-WORK 7 access. My NATURAL to ENTIRE X and NATURAL to Oracle access are unaffected. Hopefully, that won’t change.
Hello, sorry for the late answer.
I’ve asked in adabas development about the behavior of the new adalnk
The answer was: Because of additional requirements to the adalnk the interface has been changed.
NAT611 + s-bit, ADA331/09 and above and WCP7, then the adalnknc can’t be used because he doesn’t support WCP7.
On HP-UX (Itanium) the new adalnk needs the following libs during runtime for local and remote access to adabas:
$SAG/common/lib/libsagsmp2.so
$SAG/common/lib/libadamplnk.so
$SAG/common/lib/libadalnkx.so
$SAG/common/lib/libicui18n.18.1
$SAG/common/lib/libicuuc.18
$SAG/common/lib/libicudt18b.so
If there is for example a softlink from these libs to a default system runpath ( /usr/lib/hpux64 ) then it works.