Setting umask using environment variable - not a system call

[beginetienne]

Hi,

HP-UX usxsl022 B.11.31 U ia64 0309084507 unlimited-user license

I was wondering if it is possible to set the umask by setting an environment variable.  I was told on a different forum that some flavors of unix/linux allowed the following:

UMASK=022

Will this work on HP Unix ?  

I need this because we use apache and webspeed from Progress, which is basically our web transaction server.  The webspeed process runs under a user id, and it creates files with permissions rw-rw-rw.  This is not acceptable, and I need to apply umask 022 to meet some security standard we have.

Thanks,

Etienne.

[Matti_Kurkela · Accepted solution]

Umask is fundamentally not an environment variable, though it is explicitly inherited from the parent process to the child just like (exported) environment variables (see fork(2)).

The ability to set it using an environment variable syntax would probably be a feature of a specific shell, implemented by running the umask() system call as the user or a script assigns a value to a specific variable.

Are you sure your Progress is started with the correct umask? If it is started directly from /etc/inittab, it would probably inherit the kernel default umask, which has historically been 000 in HP-UX. Even if Progress is programmed to explicitly chmod() the files it creates to sane values, it might still allow its child processes to inherit the original unmodified value.

If you find no other way to configure the umask for webspeed, you might find the actual webspeed binary, rename it, and write a tiny shell script in its place. For example, if the original webspeed binary was /some/where/webspeed, you might do this:

mv /some/where/webspeed /some/where/webspeed.real
vi /some/where/webspeed
<write the script as below>
chmod 755 /some/where/webspeed

 The script /some/where/webspeed would be:

#!/bin/sh
umask 022
exec /some/where/webspeed.real "$@"

 The "exec" command will make the shell process replace itself with the real webspeed binary, so there will be no extra shell process cluttering the ps listing. And the "$@" syntax will pass all the command line parameters given to this webspeed script to the webspeed.real binary exactly as they were, even if they contain spaces or special characters.

If this kind of script does not help, it probably means webspeed is explicitly setting its own umask: in that case, it's time to read the webspeed documentation to find out how it decides the value it sets for itself. In such a case, it will probably be settable in some configuration file, but leaving it unset might cause it to default to 000.

[beginetienne]

Thanks for your reply ! As you said ultimately this might be configuration on the webspeed application.  I was not able to locate documentation about this topic.  

I have simply logged a support case Progress about this issue.

Your suggestion to locate where the actual application is launched and apply umask would most likely work! After drilling down I was able to locate the actual executable.  This will be considered a last resort change by our DBA, as the policy is to avoid customizations to files in the installation directories of apps we have purchased.

We could probably use a wrapper script or something of the sort.  

Thanks,

Etienne.