This is expected behavior resulting from the directory having the sticky bit set. It can be verified that the sticky bit is on by running:
$ ls -ld <directoryName>
Example: When the directory sticky bit is switched on, n
otice the "t" at the end of the permissions list:
drwxrwxrwt 12 root root 4096 Aug 3 09:24 /tmp
In addition to this, a directory listing (ls -l) on the temporary directory where a 4GL session is active, notice that the lbi file is owned by root, as opposed to the DBI and srt files, which are owned by the UNIX user that started up the 4GL client session. :
-rw-r--r-- 1 myuser support 3072 Aug 3 09:29 DBIl0bMpj
-rw-r--r-- 1 root support 0 Aug 3 09:29 lbiFdXs4b
-rw-r--r-- 1 myuser support 0 Aug 3 09:29 srts6lGre
The man pages for chmod with regard to the implications of the directory sticky bit, it is noted that [snipped from the man pages on Linux]:
STICKY DIRECTORIES
When the sticky bit is set on a directory, files in that directory may
be unlinked or renamed only by root or their owner. Without the sticky
bit, anyone able to write to the directory can delete or rename files.
Putting all this information together, the following is happening when the Progress client session is started up with the
Save Temp Files (-t) startup parameter and the Client Temporary file directory has the sticky bit
:
- When the 4GL client session starts up, the UNIX permissions are temporarily upgraded to those of root; that happens thanks to the sticky bit on the Progress client executable. This is the stage when the lbi file is created.
- Shortly after that, the permissions are downgraded to those of the UNIX user that started the session up [in the example above: myuser]. This is the stage when the DBI and srt files are created. Once permissions are downgraded, there is no way for the executable to gain root permissions again.
- When the 4GL session exists, the executable can clean up the DBI and srt files because they are owned by the UNIX user running the session [myuser]; on the other hand, the lbi file is owned by root, and because of the directory sticky bit, it cannot be cleaned up.
Please note that this problem does not occur if -t is not used when starting up the 4GL client session. In that case, the temporary files are unlinked without any problems when the session exits.
