<?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 Re: suid bit in Operating System - HP-UX</title>
    <link>https://community.hpe.com/t5/operating-system-hp-ux/suid-bit/m-p/3414269#M203003</link>
    <description>They need to (as most other system level commands) since they access, modify or update files that are protected and must be secured.</description>
    <pubDate>Wed, 03 Nov 2004 14:32:38 GMT</pubDate>
    <dc:creator>Alzhy</dc:creator>
    <dc:date>2004-11-03T14:32:38Z</dc:date>
    <item>
      <title>suid bit</title>
      <link>https://community.hpe.com/t5/operating-system-hp-ux/suid-bit/m-p/3414267#M203001</link>
      <description>Why is the suid bit enabled for these programs? Would any user other than root need to run these? &lt;BR /&gt;&lt;BR /&gt;/sbin/lvchange.run&lt;BR /&gt;/sbin/lvmerge&lt;BR /&gt;/sbin/lvsplit&lt;BR /&gt;/sbin/lvsync&lt;BR /&gt;/nomwcsyncd&lt;BR /&gt;/sbin/vgsync&lt;BR /&gt;&lt;BR /&gt;Thanks &lt;BR /&gt;</description>
      <pubDate>Wed, 03 Nov 2004 14:14:02 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-hp-ux/suid-bit/m-p/3414267#M203001</guid>
      <dc:creator>roger_101</dc:creator>
      <dc:date>2004-11-03T14:14:02Z</dc:date>
    </item>
    <item>
      <title>Re: suid bit</title>
      <link>https://community.hpe.com/t5/operating-system-hp-ux/suid-bit/m-p/3414268#M203002</link>
      <description>Hi Roger,&lt;BR /&gt;&lt;BR /&gt;  You can ignore the SETUID bit on these programs. The programs has internal checks to check for the real UID of the user executing the file even though SETUID has been set.&lt;BR /&gt;&lt;BR /&gt;  Infact, all the LVM commands are hard linked to the same binary - /sbin/lvchange. It is just the name of the file that differs. interesting.. isn't it ?&lt;BR /&gt;&lt;BR /&gt;- Sundar&lt;BR /&gt;&lt;BR /&gt;</description>
      <pubDate>Wed, 03 Nov 2004 14:31:46 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-hp-ux/suid-bit/m-p/3414268#M203002</guid>
      <dc:creator>Sundar_7</dc:creator>
      <dc:date>2004-11-03T14:31:46Z</dc:date>
    </item>
    <item>
      <title>Re: suid bit</title>
      <link>https://community.hpe.com/t5/operating-system-hp-ux/suid-bit/m-p/3414269#M203003</link>
      <description>They need to (as most other system level commands) since they access, modify or update files that are protected and must be secured.</description>
      <pubDate>Wed, 03 Nov 2004 14:32:38 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-hp-ux/suid-bit/m-p/3414269#M203003</guid>
      <dc:creator>Alzhy</dc:creator>
      <dc:date>2004-11-03T14:32:38Z</dc:date>
    </item>
    <item>
      <title>Re: suid bit</title>
      <link>https://community.hpe.com/t5/operating-system-hp-ux/suid-bit/m-p/3414270#M203004</link>
      <description>Just to make sure you are not mislead - even if the SUID bit is not set and if the root runs the program, the process created can bypass all the access permission settings. &lt;BR /&gt;&lt;BR /&gt;I cannot tell you why SUID is set for the lv* commands, but I can tell you it is not a security risk since LVM commands checks the REAL UID of the user before executing the operation. &lt;BR /&gt;&lt;BR /&gt;So , even if a non-root user executes lvlnboot, for example, the effective UID of the process will be 0 but REAL UID of the process will still be that of the user's UID and thus the user will not be allowed to continue.</description>
      <pubDate>Wed, 03 Nov 2004 14:43:54 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-hp-ux/suid-bit/m-p/3414270#M203004</guid>
      <dc:creator>Sundar_7</dc:creator>
      <dc:date>2004-11-03T14:43:54Z</dc:date>
    </item>
  </channel>
</rss>

