<?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: sudo Runas_Alias not working in Operating System - HP-UX</title>
    <link>https://community.hpe.com/t5/operating-system-hp-ux/sudo-runas-alias-not-working/m-p/3972331#M293169</link>
    <description>Hi Matti, Thanks a lot for the script. &lt;BR /&gt;&lt;BR /&gt;I had another requirment to provide access to our operation team to certain application folders owned by apps user. kind of access required is "mv,cp,cd,rm,...&lt;BR /&gt;Is sudo the best option or should I use ACL.</description>
    <pubDate>Fri, 30 Mar 2007 03:59:29 GMT</pubDate>
    <dc:creator>javedk</dc:creator>
    <dc:date>2007-03-30T03:59:29Z</dc:date>
    <item>
      <title>sudo Runas_Alias not working</title>
      <link>https://community.hpe.com/t5/operating-system-hp-ux/sudo-runas-alias-not-working/m-p/3972326#M293164</link>
      <description>I have installed ixsudo A.06.00-1.6.8p12 from HP site on HPUX 11.11 server. The Runas_Alias is not working rest are working fine. Following are the entries from my sudoers file.&lt;BR /&gt;&lt;BR /&gt;User_Alias      USER=ituser1, ituser2&lt;BR /&gt;Cmnd_Alias      CMD=/usr/bin/ls&lt;BR /&gt;Runas_Alias     APPS=appusr&lt;BR /&gt;&lt;BR /&gt;USER    ALL=(APPS) CMD&lt;BR /&gt;&lt;BR /&gt;while I try to do "sudo ls" after login as ituser1 I get the following eror message.&lt;BR /&gt;Sorry, user ituser1 is not allowed to execute '/usr/bin/ls' as root on hostA&lt;BR /&gt;&lt;BR /&gt;Butif I replace appusr with root in Runas_Alias then "sudo ls" works. It does not work if it is any username other than root.</description>
      <pubDate>Thu, 29 Mar 2007 16:05:16 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-hp-ux/sudo-runas-alias-not-working/m-p/3972326#M293164</guid>
      <dc:creator>javedk</dc:creator>
      <dc:date>2007-03-29T16:05:16Z</dc:date>
    </item>
    <item>
      <title>Re: sudo Runas_Alias not working</title>
      <link>https://community.hpe.com/t5/operating-system-hp-ux/sudo-runas-alias-not-working/m-p/3972327#M293165</link>
      <description>Javedk,&lt;BR /&gt;Check if user appusr has been setup correctly in the sudoers file, and permission to /usr/bin/files ...are given.&lt;BR /&gt;&lt;BR /&gt;cheers,&lt;BR /&gt;Raj&lt;BR /&gt;&lt;BR /&gt;</description>
      <pubDate>Thu, 29 Mar 2007 16:24:26 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-hp-ux/sudo-runas-alias-not-working/m-p/3972327#M293165</guid>
      <dc:creator>Raj D.</dc:creator>
      <dc:date>2007-03-29T16:24:26Z</dc:date>
    </item>
    <item>
      <title>Re: sudo Runas_Alias not working</title>
      <link>https://community.hpe.com/t5/operating-system-hp-ux/sudo-runas-alias-not-working/m-p/3972328#M293166</link>
      <description>You're saying here that ituser1 and ituser2 should be allowed to run /usr/bin/ls as appusr, not as root.&lt;BR /&gt;&lt;BR /&gt;If you try "sudo ls" as ituser1, you don't specify which user you want to run the command as... so sudo assumes you're trying to run it as root.&lt;BR /&gt;&lt;BR /&gt;The solution is to "say what you mean":&lt;BR /&gt;sudo -u appusr ls&lt;BR /&gt;&lt;BR /&gt;When building sudo functionality for normal users, I usually provide them with a small wrapper script or an alias to hide the "complex" sudo command.</description>
      <pubDate>Thu, 29 Mar 2007 16:52:54 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-hp-ux/sudo-runas-alias-not-working/m-p/3972328#M293166</guid>
      <dc:creator>Matti_Kurkela</dc:creator>
      <dc:date>2007-03-29T16:52:54Z</dc:date>
    </item>
    <item>
      <title>Re: sudo Runas_Alias not working</title>
      <link>https://community.hpe.com/t5/operating-system-hp-ux/sudo-runas-alias-not-working/m-p/3972329#M293167</link>
      <description>Hi Matti,&lt;BR /&gt;&lt;BR /&gt;Thank you very much for the clarification. I was assuming that it would automaticlly run the command as appusr. &lt;BR /&gt;&lt;BR /&gt;Could you please provide me a sample  wrapper script.</description>
      <pubDate>Fri, 30 Mar 2007 03:10:54 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-hp-ux/sudo-runas-alias-not-working/m-p/3972329#M293167</guid>
      <dc:creator>javedk</dc:creator>
      <dc:date>2007-03-30T03:10:54Z</dc:date>
    </item>
    <item>
      <title>Re: sudo Runas_Alias not working</title>
      <link>https://community.hpe.com/t5/operating-system-hp-ux/sudo-runas-alias-not-working/m-p/3972330#M293168</link>
      <description>It could be as simple as this:&lt;BR /&gt;&lt;BR /&gt;#!/bin/sh&lt;BR /&gt;exec sudo -u appusr "$@"&lt;BR /&gt;&lt;BR /&gt;Name it something suitable (maybe "appusr"?), put it in /usr/local/bin or some other location that is in the users' PATH and give it execute permissions.&lt;BR /&gt;&lt;BR /&gt;The script can now be used like this:&lt;BR /&gt;&lt;BR /&gt;appusr ls -lt /some/directory/somewhere&lt;BR /&gt;&lt;BR /&gt;with an unlimited number of arguments. It works like a simple "prefix" in front of the desired command.</description>
      <pubDate>Fri, 30 Mar 2007 03:41:07 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-hp-ux/sudo-runas-alias-not-working/m-p/3972330#M293168</guid>
      <dc:creator>Matti_Kurkela</dc:creator>
      <dc:date>2007-03-30T03:41:07Z</dc:date>
    </item>
    <item>
      <title>Re: sudo Runas_Alias not working</title>
      <link>https://community.hpe.com/t5/operating-system-hp-ux/sudo-runas-alias-not-working/m-p/3972331#M293169</link>
      <description>Hi Matti, Thanks a lot for the script. &lt;BR /&gt;&lt;BR /&gt;I had another requirment to provide access to our operation team to certain application folders owned by apps user. kind of access required is "mv,cp,cd,rm,...&lt;BR /&gt;Is sudo the best option or should I use ACL.</description>
      <pubDate>Fri, 30 Mar 2007 03:59:29 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-hp-ux/sudo-runas-alias-not-working/m-p/3972331#M293169</guid>
      <dc:creator>javedk</dc:creator>
      <dc:date>2007-03-30T03:59:29Z</dc:date>
    </item>
    <item>
      <title>Re: sudo Runas_Alias not working</title>
      <link>https://community.hpe.com/t5/operating-system-hp-ux/sudo-runas-alias-not-working/m-p/3972332#M293170</link>
      <description>Allowing a basic file manipulation access *and only that* is a bit laborious with sudo, although certainly do-able. &lt;BR /&gt;&lt;BR /&gt;Since "cd" is a shell built-in command, you cannot use sudo for that. Possible workarounds would be to instruct the users to use full pathnames of the files they intend to manipulate. However, most users don't like to type long path names at every command (autocompletion may not work, as the shell that does the completion is run as the user's normal identity, and may not have the permissions to read the application directories).&lt;BR /&gt;&lt;BR /&gt;The easiest (but not the most audit-proof) solution would be to allow the users to run a shell as appusr (sudo -u appusr /usr/bin/sh, or sudo -u appusr -s). If a secure logging for commands is a requirement, this may not be a valid solution.&lt;BR /&gt;&lt;BR /&gt;If this is a new system, you should consider using the group permissions for files and directories.&lt;BR /&gt;For example:&lt;BR /&gt;- appusr belongs to group appgrp&lt;BR /&gt;- users ituser1 and ituser2 have "appgrp" as a secondary group (usermod -G); the primary group can be anything you like&lt;BR /&gt;&lt;BR /&gt;- the application *directories* have owner appuser, group appgrp and chmod 2770 (setgid appgrp).&lt;BR /&gt;&lt;BR /&gt;- the application *files* have group appgrp and chmod 0660 (group writable, no setuid/setgid)&lt;BR /&gt;&lt;BR /&gt;Now ituser1 and ituser2 can manipulate the application files *using their own identity* and any new files created/moved in application directories get the group "appgrp". If the user sets "umask 007" before manipulating application files, everything works: the application has full access to the directories and files because it is member of the appgrp group and the files are group writable.&lt;BR /&gt;&lt;BR /&gt;Caveat: if the user forgets to enter "umask 007" before manipulating application files, he/she may cause the manipulated files to become writeable only for him/her. If the files are readable by other members of the appgrp group, this is user-fixable: any member of the group can copy the file and remove the original (to eliminate the file with wrong permissions). If the file is readable only by the user that made the mistake, only that user (or someone with root powers) can undo the mistake. &lt;BR /&gt;This can cause some extra workload for admins, until the users learn the system.&lt;BR /&gt;</description>
      <pubDate>Fri, 30 Mar 2007 06:15:57 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-hp-ux/sudo-runas-alias-not-working/m-p/3972332#M293170</guid>
      <dc:creator>Matti_Kurkela</dc:creator>
      <dc:date>2007-03-30T06:15:57Z</dc:date>
    </item>
    <item>
      <title>Re: sudo Runas_Alias not working</title>
      <link>https://community.hpe.com/t5/operating-system-hp-ux/sudo-runas-alias-not-working/m-p/3972333#M293171</link>
      <description>Thanks a lot. Great response...</description>
      <pubDate>Fri, 30 Mar 2007 10:50:15 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-hp-ux/sudo-runas-alias-not-working/m-p/3972333#M293171</guid>
      <dc:creator>javedk</dc:creator>
      <dc:date>2007-03-30T10:50:15Z</dc:date>
    </item>
  </channel>
</rss>

