Find the answer to your Linux question:
Page 1 of 2 1 2 LastLast
Results 1 to 10 of 11
Enjoy an ad free experience by logging in. Not a member yet? Register.
  1. #1
    Just Joined! jdh239's Avatar
    Join Date
    Sep 2006
    Posts
    94

    Prevent all users from executing a command (even root)


    We have a command that will bring down our servers depending on our patch level. We would like to alias this command to something harmless, or disable it all together. Removing it isn't an option.

    The command that hurts:
    xm debug -D

    Other xm debug -* commands run regularly, it is just this particular one that is killing us. This has been reported to the vendor, but we need something in the mean time as we wait for a fix (hopefully they fix it).

    Any ideas?

  2. #2
    Linux Guru Rubberman's Avatar
    Join Date
    Apr 2009
    Location
    I can be found either 40 miles west of Chicago, in Chicago, or in a galaxy far, far away.
    Posts
    14,038
    Put the xm commands in a shell script and disallow access to this one altogether.
    Sometimes, real fast is almost as good as real time.
    Just remember, Semper Gumbi - always be flexible!

  3. #3
    Just Joined! jdh239's Avatar
    Join Date
    Sep 2006
    Posts
    94
    How do you mean? The xm command has valid functions, but it is "xm debug-keys -D" that I need to disable, leaving all other functionality in place.

  4. $spacer_open
    $spacer_close
  5. #4
    Linux Guru Rubberman's Avatar
    Join Date
    Apr 2009
    Location
    I can be found either 40 miles west of Chicago, in Chicago, or in a galaxy far, far away.
    Posts
    14,038
    It's not rocket science. You put all the xm commands in a shell script and put the -D option in a branch that only root can access. If you don't know how to do that, then you need to study how bash works.
    Sometimes, real fast is almost as good as real time.
    Just remember, Semper Gumbi - always be flexible!

  6. #5
    Just Joined! jdh239's Avatar
    Join Date
    Sep 2006
    Posts
    94
    Quote Originally Posted by Rubberman View Post
    It's not rocket science. You put all the xm commands in a shell script and put the -D option in a branch that only root can access. If you don't know how to do that, then you need to study how bash works.
    I know how bash works, however, I found your response light on details. I am trying to clarify what you meant in your initial response.

    To me, it sounds like you are moving the binary out of the normal paths and replacing it with a bash script. If I misunderstand perhaps you could clarify. Without removing the binary I don't see how this would prevent somebody from executing the command.

  7. #6
    Linux Guru Rubberman's Avatar
    Join Date
    Apr 2009
    Location
    I can be found either 40 miles west of Chicago, in Chicago, or in a galaxy far, far away.
    Posts
    14,038
    You do remove the binary and place it in the shell script. The binary is then no longer available in /bin or /usr/bin.
    Sometimes, real fast is almost as good as real time.
    Just remember, Semper Gumbi - always be flexible!

  8. #7
    Linux Newbie sarlacii's Avatar
    Join Date
    May 2005
    Location
    South Africa
    Posts
    223
    Hi jdh239, I think that you are talking cross-purpose to Rubberman. To clarify what has been suggested, I think:
    1. Move the binary out of the path, and place it in some other folder (/opt/dangerousBinary/).
    2. Create a script with the same name as the original binary, and place it in the path. Make sure that it takes in command line switches, to feed to the binary when you call it.
    3. Inside the script you catch the command that you don't want to run, and exit the script with a message telling the user what happened
    4. The rest of the command combinations you allow to execute, from inside the script.

    Go well.

  9. #8
    Linux Guru
    Join Date
    Dec 2013
    Posts
    2,747
    to clarify further:
    in your $PATH, $HOME/bin usually comes before the system bin directories.
    if you place a custom script there that has the same name as that other dangerous program, it will take precedence.

  10. #9
    Linux Guru Rubberman's Avatar
    Join Date
    Apr 2009
    Location
    I can be found either 40 miles west of Chicago, in Chicago, or in a galaxy far, far away.
    Posts
    14,038
    Quote Originally Posted by sarlacii View Post
    Hi jdh239, I think that you are talking cross-purpose to Rubberman. To clarify what has been suggested, I think:
    1. Move the binary out of the path, and place it in some other folder (/opt/dangerousBinary/).
    2. Create a script with the same name as the original binary, and place it in the path. Make sure that it takes in command line switches, to feed to the binary when you call it.
    3. Inside the script you catch the command that you don't want to run, and exit the script with a message telling the user what happened
    4. The rest of the command combinations you allow to execute, from inside the script.

    Go well.
    Well put!
    Sometimes, real fast is almost as good as real time.
    Just remember, Semper Gumbi - always be flexible!

  11. #10
    Just Joined! jdh239's Avatar
    Join Date
    Sep 2006
    Posts
    94

    Solved

    -->
    Thanks all. I know there is probably a more succinct way to write this, but it is working. I didn't get it to work via getopts. Posting here for others to use should they choose.

    Code:
    #!/bin/bash
    
    # Capture options to execute later if missing bad options
    cmd_options=()
    for i in "$@"; do
       shift
       cmd_options+=("$i")
    done
    
    # Check for bad options and exit if found
    for i in "${cmd_options[@]}"; do
      shift
      case "$i" in
        "D"|"e"|"-D"|"-e")
          printf "\n\tSkipping command option \"${i}\" due to it locking up the server in the past.\n\n"
          exit 1
                    ;;
      esac
    done
    
    # Execute actual xm command with original options
    /usr/sbin/xmbin ${cmd_options[@]}
    Last edited by jdh239; 11-08-2017 at 01:14 PM.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •