Beefy Boxes and Bandwidth Generously Provided by pair Networks
There's more than one way to do things

Executing Root Commands from user level

by curtisb (Monk)
on Jan 18, 2002 at 20:06 UTC ( #139844=perlquestion: print w/replies, xml ) Need Help??

curtisb has asked for the wisdom of the Perl Monks concerning the following question:

Ok, I have a question. I want to execute a script, which is currently in shell scripting (sh), that does an su to root. Where you have to enter the password. Then I want to execute the commands as root then exit back to user level.

What I have written is this:

#!/bin/sh echo "Enter password when prompted"; su - cd /www/apache/bin ./apachectl start exit

Now I know that there is a better way to do this through perl. Does anyone have any clues on where I should start looking. My biggest problem is switching from one user to root, excuteing the commands, and then exiting.

Please Help!



Replies are listed 'Best First'.
Re: Executing Root Commands from user level
by arhuman (Vicar) on Jan 18, 2002 at 20:30 UTC
    Your solution is sudo !
    (I tend to use it instead of suidperl)
    Whatever the language you use for your prog (shell,Perl,C)
    You can even allow some users to execute some commands as root without entering root passwd
    (a LOT safer to my mind).

    "Only Bad Coders Code Badly In Perl" (OBC2BIP)
Re: Executing Root Commands from user level
by Masem (Monsignor) on Jan 18, 2002 at 20:31 UTC
    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
    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 - || "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

      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)
        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 - || "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

Log In?

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: perlquestion [id://139844]
Approved by root
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others lurking in the Monastery: (4)
As of 2023-06-10 18:14 GMT
Find Nodes?
    Voting Booth?
    How often do you go to conferences?

    Results (39 votes). Check out past polls.