UMASK = 000 inetd init script

[Jayme Frye_1]

We have some thrid party processes that run out of inetd. The processes write out some log files mode 666. The processes take for granted that they have inherited a sane umask value from inetd. The HP provided init script for inetd ( which admonishes users not to edit it ) sets the umask to 000

mask=`umask`
umask 000
What is the purpose of doing this? I don't see this behaviour on Solaris or Linux. Note HP does the sane thing earlier in the init process by setting the umask to 022 in /sbin/rc, but for some as yet inexplicable reason in the inetd script it resets it to 000.

[A. Clay Stephenson]

You can certainly change the umask setting in /sbin/init.d/inetd - the boiler-plate admonishment really justs lets you know that patches / OS upgrades are possibly going to overwrite your changes. This is meant to encourage changes to be made in the /etc/rc.config.d files instead. In the case of inetd, I suspect that the most noticable change will be that rdist will be using a different umask. If you use rdist, it's possible that distributed files will have more restrictive permissions.

The other obvious answer is to run a cronjob to change the permissions after the log files have been created.

A little more difficult would be to create a wrapper program which would set ulimit and then exec() your 3rd-party daemon.

[Joseph C. Denman]

I think Clay has covered it very well.

Another point to remember. The files created by inetd are owned by root. If you change the umask........only root will be able to access.


...jcd...

[Bill Hassell]

umask = 000 is a long standing problem in HP-UX and has been reported several times. Since the basic rule in security is to ASSUME NOTHING, I would never write any system level script that uses $PATH or umask or any other inherited environment values in any part of the code.

[Jayme Frye_1]

Thanks all for responding. I'll be working with the vendors to correct their code. I am however, still wondering what HP's intent is with forcing a umask of 000 in the inetd startup script. Since it seems so deliberate and its been reported before there must be some reason it has not been changed.

[Bill Thorsteinson]

A tighter umask will prevent
anyone but root from writing
files created during startup.
This is not necessarily a bad
thing, but HP seems to prefer
it this way.

It allows non-root usrs to write startup log files. This
allows programs that start as root and change user id to
reopen and append to their logs. Is saves a chown on the log file at the expense of
some security. There are
better approaches.

If you want tigher security
on the log files, then you
should consider changing the
umask value in the startup
script for the processes.

Standard values for umask octets are 0 (all access), 2
(read-only), and 7 (no access).

Depending on paranoia levels, umask values of 022, 027, and
077 are typical. All values require some management of
access rights