<?xml version="1.0" encoding="UTF-8"?>
<rss xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" version="2.0">
  <channel>
    <title>topic UMASK = 000 inetd init script in Operating System - HP-UX</title>
    <link>https://community.hpe.com/t5/operating-system-hp-ux/umask-000-inetd-init-script/m-p/2797638#M754261</link>
    <description>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&lt;BR /&gt;&lt;BR /&gt;                   mask=`umask`&lt;BR /&gt;                   umask 000&lt;BR /&gt;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.&lt;BR /&gt;</description>
    <pubDate>Fri, 30 Aug 2002 15:43:36 GMT</pubDate>
    <dc:creator>Jayme Frye_1</dc:creator>
    <dc:date>2002-08-30T15:43:36Z</dc:date>
    <item>
      <title>UMASK = 000 inetd init script</title>
      <link>https://community.hpe.com/t5/operating-system-hp-ux/umask-000-inetd-init-script/m-p/2797638#M754261</link>
      <description>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&lt;BR /&gt;&lt;BR /&gt;                   mask=`umask`&lt;BR /&gt;                   umask 000&lt;BR /&gt;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.&lt;BR /&gt;</description>
      <pubDate>Fri, 30 Aug 2002 15:43:36 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-hp-ux/umask-000-inetd-init-script/m-p/2797638#M754261</guid>
      <dc:creator>Jayme Frye_1</dc:creator>
      <dc:date>2002-08-30T15:43:36Z</dc:date>
    </item>
    <item>
      <title>Re: UMASK = 000 inetd init script</title>
      <link>https://community.hpe.com/t5/operating-system-hp-ux/umask-000-inetd-init-script/m-p/2797639#M754262</link>
      <description>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. &lt;BR /&gt;&lt;BR /&gt;The other obvious answer is to run a cronjob to change the permissions after the log files have been created.&lt;BR /&gt;&lt;BR /&gt;A little more difficult would be to create a wrapper program which would set ulimit and then exec() your 3rd-party daemon.&lt;BR /&gt;&lt;BR /&gt;</description>
      <pubDate>Fri, 30 Aug 2002 16:07:49 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-hp-ux/umask-000-inetd-init-script/m-p/2797639#M754262</guid>
      <dc:creator>A. Clay Stephenson</dc:creator>
      <dc:date>2002-08-30T16:07:49Z</dc:date>
    </item>
    <item>
      <title>Re: UMASK = 000 inetd init script</title>
      <link>https://community.hpe.com/t5/operating-system-hp-ux/umask-000-inetd-init-script/m-p/2797640#M754263</link>
      <description>I think Clay has covered it very well.&lt;BR /&gt;&lt;BR /&gt;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.&lt;BR /&gt;&lt;BR /&gt;&lt;BR /&gt;...jcd...</description>
      <pubDate>Fri, 30 Aug 2002 16:15:58 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-hp-ux/umask-000-inetd-init-script/m-p/2797640#M754263</guid>
      <dc:creator>Joseph C. Denman</dc:creator>
      <dc:date>2002-08-30T16:15:58Z</dc:date>
    </item>
    <item>
      <title>Re: UMASK = 000 inetd init script</title>
      <link>https://community.hpe.com/t5/operating-system-hp-ux/umask-000-inetd-init-script/m-p/2797641#M754264</link>
      <description>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.</description>
      <pubDate>Fri, 30 Aug 2002 20:53:46 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-hp-ux/umask-000-inetd-init-script/m-p/2797641#M754264</guid>
      <dc:creator>Bill Hassell</dc:creator>
      <dc:date>2002-08-30T20:53:46Z</dc:date>
    </item>
    <item>
      <title>Re: UMASK = 000 inetd init script</title>
      <link>https://community.hpe.com/t5/operating-system-hp-ux/umask-000-inetd-init-script/m-p/2797642#M754265</link>
      <description>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.</description>
      <pubDate>Tue, 03 Sep 2002 14:40:47 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-hp-ux/umask-000-inetd-init-script/m-p/2797642#M754265</guid>
      <dc:creator>Jayme Frye_1</dc:creator>
      <dc:date>2002-09-03T14:40:47Z</dc:date>
    </item>
    <item>
      <title>Re: UMASK = 000 inetd init script</title>
      <link>https://community.hpe.com/t5/operating-system-hp-ux/umask-000-inetd-init-script/m-p/2797643#M754266</link>
      <description>A tighter umask will prevent &lt;BR /&gt;anyone but root from writing&lt;BR /&gt;files created during startup. &lt;BR /&gt;This is not necessarily a bad&lt;BR /&gt;thing, but HP seems to prefer&lt;BR /&gt;it this way.  &lt;BR /&gt;&lt;BR /&gt;It allows non-root usrs to write startup log files.  This&lt;BR /&gt;allows programs that start as root and change user id to&lt;BR /&gt;reopen and append to their logs. Is saves a chown on the log file at the expense of &lt;BR /&gt;some security.  There are &lt;BR /&gt;better approaches.&lt;BR /&gt;&lt;BR /&gt;If you want tigher security&lt;BR /&gt;on the log files, then you &lt;BR /&gt;should consider changing the&lt;BR /&gt;umask value in the startup&lt;BR /&gt;script for the processes.&lt;BR /&gt;&lt;BR /&gt;Standard values for umask octets are 0 (all access), 2&lt;BR /&gt;(read-only), and 7 (no access).  &lt;BR /&gt;&lt;BR /&gt;Depending on paranoia levels, umask values of 022, 027, and&lt;BR /&gt;077 are typical.  All values require some management of &lt;BR /&gt;access rights</description>
      <pubDate>Tue, 03 Sep 2002 16:13:09 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-hp-ux/umask-000-inetd-init-script/m-p/2797643#M754266</guid>
      <dc:creator>Bill Thorsteinson</dc:creator>
      <dc:date>2002-09-03T16:13:09Z</dc:date>
    </item>
  </channel>
</rss>

