in reply to Executing Root Commands from user level

I don't believe you are going to find a better way. Running perl is not automagically going to give you any root priviledges, and you'll still have to do some su'ing to the root level to make things work.

A much better solution (IMO) is to create a script that has the group suid set (that is "rwxrws---"), created by root, with the group containing only those people that you want to be able to run the script from their accounts. The suid bit allows programs that require access to root-level resources to temporarily gain them, and is typically used for direct interaction with the hardward (like X) or with the lower ports (like httpd). But since it has that power, you want to limit who can run it, particularly if you are on a shared-user box. This script can be done in perl, but based on what you have above, it can be as simple as this shell script 

#!/bin/sh
/www/apache/bin/apachectl start

[download]
Do note that you have to have your root user create this and set the bits and set up the group appropriately. A non-root user can't (or shouldn't, at least) be able to grant suid status to a file.

-----------------------------------------------------
Dr. Michael K. Neylon - mneylon-pm@masemware.com || "You've left the lens cap of your mind on again, Pinky" - The Brain
"I can see my house from here!"
It's not what you know, but knowing how to find it if you don't know that's important

Replies are listed 'Best First'.
Re: Re: Executing Root Commands from user level
by arhuman (Vicar) on Jan 18, 2002 at 20:36 UTC
    I would not recommend this.

    Some people already took some time to explain why SUID shell script can not be secure.
    (In fact some OS simply forbidd them for that reason...)

    Just my humble opinion although...


    "Only Bad Coders Code Badly In Perl" (OBC2BIP)
[reply]
      True, a C-shell-based SUID script can be very insecure, though with a script this simple, all the user would have to do is make sure the PATH is set specifically. Or as the article states, this could also be done directly in perl, thus removing much of the insecurity overhead with Cshell scripts.

      However, at least IMO, I would think that being able to set one 'program' to be SUID for a specific group of users is better than allowing one user SUDO access, as the former is more specific about what you are allowing. Say the box is a web dev box, as it appears, and you have teammember Bob on it would does script developement; Bob, while compentent, isn't fully trustworthy at least to your team, but management says he needs to be able to change web server configurations and restart the http server for him to work. Allowing Bob SUDO access to the box could be very very bad, if he truly is a problem. On the other hand, allowing Bob into the access group that can run the apache restart program via a suid bit, means that the only damage he can effectively do (besides erasing config files) is starting and stoping the web server; the rest of the box remains secure. In addition, if Bob's account was broken into by someone more malicious than Bob, and BOB had SUDO access, you could kiss your box goodbye; limiting what can be done via suid programs will prevent a total compramise of the box.

      -----------------------------------------------------
      Dr. Michael K. Neylon - mneylon-pm@masemware.com || "You've left the lens cap of your mind on again, Pinky" - The Brain
      "I can see my house from here!"
      It's not what you know, but knowing how to find it if you don't know that's important

[reply]
        Allowing Bob SUDO access to the box could be very very bad, if he truly is a problem. On the other hand, allowing Bob into the access group that can run the apache restart program via a suid bit, means that the only damage he can effectively do (besides erasing config files) is starting and stoping the web server; the rest of the box remains secure.

        Either I miss somthing either you ignore that sudo can be configured to grant precise/limited access to some prog.

        User_Alias  WEBMASTERS = user1, user2, user3
User_Alias  SYSADMINS  = user3, user2
User_Alias  DUMBUSERS  = user4

# User privilege specification
root    ALL=(ALL) ALL
WEBMASTERS      www = NOPASSWD: /usr/sbin/apachectl
SYSADMINS       wiz = NOPASSWD: /bin/wiz
DUMBUSERS       blah = NOPASSWD: /bin/blah

        [download]

        Here I allow user1,user2,user3 (WEBMASTERS's sudo group) to use apachectl
        Here I allow user2,user3 (SYSADMINS's sudo group) to use the ueber-elite /bin/wiz command
        Here I allow user4 (DUMBUSERS's sudo group) to use the /bin/blah (I really don't trust him ;-)

        If an intruder compromise the user4 account he can't do more than executing /bin/blah.

        Sudo offer tons of other features (ask for passwd, execute under other UID...).
        You really should give it a try...


        "Only Bad Coders Code Badly In Perl" (OBC2BIP)
[reply]
[d/l]

In Section Seekers of Perl Wisdom