Specify command with quoted arguments in sudoers?

The name of the pictureThe name of the pictureThe name of the pictureClash Royale CLAN TAG#URR8PPP











up vote
1
down vote

favorite












The General Case



I'm trying to enable a user to run a sudo command (with arguments) without a password. I can get the NOPASSWD directive to work, but only when the arguments don't contain quotation marks.



For example, this works:



# /etc/sudoers.d/sample
%sudo ALL=(ALL) NOPASSWD: /bin/echo foo

$ sudo echo foo
foo


But this doesn't, because quotation marks are interpreted literally:



# /etc/sudoers.d/sample
%sudo ALL=(ALL) NOPASSWD: /bin/echo "foo"

$ sudo echo "foo"
[sudo] password for rlue:
$ sudo echo "foo"
"foo"



My Specific Case



This is the command I'm trying to allow:



$ sudo sh -c 'echo XHCI > /proc/acpi/wakeup'


I actually got it to work with the following unquoted command:



%sudo ALL=(ALL) NOPASSWD: /bin/sh -c echo XHCI > /proc/acpi/wakeup


But since it calls out to sh -c, and since I clearly don't understand precisely what's going on, I'd like to be extra explicit about what I'm allowing.



How can I specify quoting for command arguments in the sudoers file?







share|improve this question



















  • The sudoers man page says "If a Cmnd has associated command line arguments, then the arguments ... must match exactly those given by the user...", so you're already being "extra explicit" about what you're allowing.
    – dsstorefile1
    May 9 at 3:16










  • Sure, but for example, mv this that the other is different from mv this that 'the other', and the unquoted syntax permits both. How can I be sure I haven't missed any edge cases?
    – Ryan Lue
    May 9 at 3:32






  • 1




    If you're worried about edge cases, see serverfault.com/a/516002. Apparently, that is the "simple solution".
    – dsstorefile1
    May 9 at 3:41














up vote
1
down vote

favorite












The General Case



I'm trying to enable a user to run a sudo command (with arguments) without a password. I can get the NOPASSWD directive to work, but only when the arguments don't contain quotation marks.



For example, this works:



# /etc/sudoers.d/sample
%sudo ALL=(ALL) NOPASSWD: /bin/echo foo

$ sudo echo foo
foo


But this doesn't, because quotation marks are interpreted literally:



# /etc/sudoers.d/sample
%sudo ALL=(ALL) NOPASSWD: /bin/echo "foo"

$ sudo echo "foo"
[sudo] password for rlue:
$ sudo echo "foo"
"foo"



My Specific Case



This is the command I'm trying to allow:



$ sudo sh -c 'echo XHCI > /proc/acpi/wakeup'


I actually got it to work with the following unquoted command:



%sudo ALL=(ALL) NOPASSWD: /bin/sh -c echo XHCI > /proc/acpi/wakeup


But since it calls out to sh -c, and since I clearly don't understand precisely what's going on, I'd like to be extra explicit about what I'm allowing.



How can I specify quoting for command arguments in the sudoers file?







share|improve this question



















  • The sudoers man page says "If a Cmnd has associated command line arguments, then the arguments ... must match exactly those given by the user...", so you're already being "extra explicit" about what you're allowing.
    – dsstorefile1
    May 9 at 3:16










  • Sure, but for example, mv this that the other is different from mv this that 'the other', and the unquoted syntax permits both. How can I be sure I haven't missed any edge cases?
    – Ryan Lue
    May 9 at 3:32






  • 1




    If you're worried about edge cases, see serverfault.com/a/516002. Apparently, that is the "simple solution".
    – dsstorefile1
    May 9 at 3:41












up vote
1
down vote

favorite









up vote
1
down vote

favorite











The General Case



I'm trying to enable a user to run a sudo command (with arguments) without a password. I can get the NOPASSWD directive to work, but only when the arguments don't contain quotation marks.



For example, this works:



# /etc/sudoers.d/sample
%sudo ALL=(ALL) NOPASSWD: /bin/echo foo

$ sudo echo foo
foo


But this doesn't, because quotation marks are interpreted literally:



# /etc/sudoers.d/sample
%sudo ALL=(ALL) NOPASSWD: /bin/echo "foo"

$ sudo echo "foo"
[sudo] password for rlue:
$ sudo echo "foo"
"foo"



My Specific Case



This is the command I'm trying to allow:



$ sudo sh -c 'echo XHCI > /proc/acpi/wakeup'


I actually got it to work with the following unquoted command:



%sudo ALL=(ALL) NOPASSWD: /bin/sh -c echo XHCI > /proc/acpi/wakeup


But since it calls out to sh -c, and since I clearly don't understand precisely what's going on, I'd like to be extra explicit about what I'm allowing.



How can I specify quoting for command arguments in the sudoers file?







share|improve this question











The General Case



I'm trying to enable a user to run a sudo command (with arguments) without a password. I can get the NOPASSWD directive to work, but only when the arguments don't contain quotation marks.



For example, this works:



# /etc/sudoers.d/sample
%sudo ALL=(ALL) NOPASSWD: /bin/echo foo

$ sudo echo foo
foo


But this doesn't, because quotation marks are interpreted literally:



# /etc/sudoers.d/sample
%sudo ALL=(ALL) NOPASSWD: /bin/echo "foo"

$ sudo echo "foo"
[sudo] password for rlue:
$ sudo echo "foo"
"foo"



My Specific Case



This is the command I'm trying to allow:



$ sudo sh -c 'echo XHCI > /proc/acpi/wakeup'


I actually got it to work with the following unquoted command:



%sudo ALL=(ALL) NOPASSWD: /bin/sh -c echo XHCI > /proc/acpi/wakeup


But since it calls out to sh -c, and since I clearly don't understand precisely what's going on, I'd like to be extra explicit about what I'm allowing.



How can I specify quoting for command arguments in the sudoers file?









share|improve this question










share|improve this question




share|improve this question









asked May 9 at 3:02









Ryan Lue

1947




1947











  • The sudoers man page says "If a Cmnd has associated command line arguments, then the arguments ... must match exactly those given by the user...", so you're already being "extra explicit" about what you're allowing.
    – dsstorefile1
    May 9 at 3:16










  • Sure, but for example, mv this that the other is different from mv this that 'the other', and the unquoted syntax permits both. How can I be sure I haven't missed any edge cases?
    – Ryan Lue
    May 9 at 3:32






  • 1




    If you're worried about edge cases, see serverfault.com/a/516002. Apparently, that is the "simple solution".
    – dsstorefile1
    May 9 at 3:41
















  • The sudoers man page says "If a Cmnd has associated command line arguments, then the arguments ... must match exactly those given by the user...", so you're already being "extra explicit" about what you're allowing.
    – dsstorefile1
    May 9 at 3:16










  • Sure, but for example, mv this that the other is different from mv this that 'the other', and the unquoted syntax permits both. How can I be sure I haven't missed any edge cases?
    – Ryan Lue
    May 9 at 3:32






  • 1




    If you're worried about edge cases, see serverfault.com/a/516002. Apparently, that is the "simple solution".
    – dsstorefile1
    May 9 at 3:41















The sudoers man page says "If a Cmnd has associated command line arguments, then the arguments ... must match exactly those given by the user...", so you're already being "extra explicit" about what you're allowing.
– dsstorefile1
May 9 at 3:16




The sudoers man page says "If a Cmnd has associated command line arguments, then the arguments ... must match exactly those given by the user...", so you're already being "extra explicit" about what you're allowing.
– dsstorefile1
May 9 at 3:16












Sure, but for example, mv this that the other is different from mv this that 'the other', and the unquoted syntax permits both. How can I be sure I haven't missed any edge cases?
– Ryan Lue
May 9 at 3:32




Sure, but for example, mv this that the other is different from mv this that 'the other', and the unquoted syntax permits both. How can I be sure I haven't missed any edge cases?
– Ryan Lue
May 9 at 3:32




1




1




If you're worried about edge cases, see serverfault.com/a/516002. Apparently, that is the "simple solution".
– dsstorefile1
May 9 at 3:41




If you're worried about edge cases, see serverfault.com/a/516002. Apparently, that is the "simple solution".
– dsstorefile1
May 9 at 3:41










1 Answer
1






active

oldest

votes

















up vote
0
down vote













edit: Warning, it appears that sudo does not safely handle spaces in the command, so it is not safe to use sudo in this way. https://unix.stackexchange.com/a/279142/39281



Instead of using quotes in the sudoers file, you can escape spaces using backslash:



%sudo ALL=(ALL) NOPASSWD: /bin/sh -c echo XHCI > /proc/acpi/wakeup


You can still use it as follows, because the user's shell handles the quoted argument anyway:



sudo /bin/sh -c 'echo XHCI > /proc/acpi/wakeup'


You could also consider putting a complex command into a script, as suggested in a comment. https://serverfault.com/a/516002






share|improve this answer























  • This appears semantically identical to not having backslashes (that is, the arguments can still be grouped with quotation marks in every possible arrangement).
    – Ryan Lue
    May 9 at 7:03










  • Someone commented: there's an other QA telling this is possibly unsafe: unix.stackexchange.com/questions/279125/… then removed their comment. But they were right, it is unsafe, seems like sudo is not safe to be used when there are spaces in the command name. Perhaps I am misusing it, or perhaps it is a rubbish insecure tool. If it is so easy to misuse, I suggest the latter.
    – Sam Watkins
    May 9 at 7:53










Your Answer







StackExchange.ready(function()
var channelOptions =
tags: "".split(" "),
id: "106"
;
initTagRenderer("".split(" "), "".split(" "), channelOptions);

StackExchange.using("externalEditor", function()
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled)
StackExchange.using("snippets", function()
createEditor();
);

else
createEditor();

);

function createEditor()
StackExchange.prepareEditor(
heartbeatType: 'answer',
convertImagesToLinks: false,
noModals: false,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
);



);








 

draft saved


draft discarded


















StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f442671%2fspecify-command-with-quoted-arguments-in-sudoers%23new-answer', 'question_page');

);

Post as a guest






























1 Answer
1






active

oldest

votes








1 Answer
1






active

oldest

votes









active

oldest

votes






active

oldest

votes








up vote
0
down vote













edit: Warning, it appears that sudo does not safely handle spaces in the command, so it is not safe to use sudo in this way. https://unix.stackexchange.com/a/279142/39281



Instead of using quotes in the sudoers file, you can escape spaces using backslash:



%sudo ALL=(ALL) NOPASSWD: /bin/sh -c echo XHCI > /proc/acpi/wakeup


You can still use it as follows, because the user's shell handles the quoted argument anyway:



sudo /bin/sh -c 'echo XHCI > /proc/acpi/wakeup'


You could also consider putting a complex command into a script, as suggested in a comment. https://serverfault.com/a/516002






share|improve this answer























  • This appears semantically identical to not having backslashes (that is, the arguments can still be grouped with quotation marks in every possible arrangement).
    – Ryan Lue
    May 9 at 7:03










  • Someone commented: there's an other QA telling this is possibly unsafe: unix.stackexchange.com/questions/279125/… then removed their comment. But they were right, it is unsafe, seems like sudo is not safe to be used when there are spaces in the command name. Perhaps I am misusing it, or perhaps it is a rubbish insecure tool. If it is so easy to misuse, I suggest the latter.
    – Sam Watkins
    May 9 at 7:53














up vote
0
down vote













edit: Warning, it appears that sudo does not safely handle spaces in the command, so it is not safe to use sudo in this way. https://unix.stackexchange.com/a/279142/39281



Instead of using quotes in the sudoers file, you can escape spaces using backslash:



%sudo ALL=(ALL) NOPASSWD: /bin/sh -c echo XHCI > /proc/acpi/wakeup


You can still use it as follows, because the user's shell handles the quoted argument anyway:



sudo /bin/sh -c 'echo XHCI > /proc/acpi/wakeup'


You could also consider putting a complex command into a script, as suggested in a comment. https://serverfault.com/a/516002






share|improve this answer























  • This appears semantically identical to not having backslashes (that is, the arguments can still be grouped with quotation marks in every possible arrangement).
    – Ryan Lue
    May 9 at 7:03










  • Someone commented: there's an other QA telling this is possibly unsafe: unix.stackexchange.com/questions/279125/… then removed their comment. But they were right, it is unsafe, seems like sudo is not safe to be used when there are spaces in the command name. Perhaps I am misusing it, or perhaps it is a rubbish insecure tool. If it is so easy to misuse, I suggest the latter.
    – Sam Watkins
    May 9 at 7:53












up vote
0
down vote










up vote
0
down vote









edit: Warning, it appears that sudo does not safely handle spaces in the command, so it is not safe to use sudo in this way. https://unix.stackexchange.com/a/279142/39281



Instead of using quotes in the sudoers file, you can escape spaces using backslash:



%sudo ALL=(ALL) NOPASSWD: /bin/sh -c echo XHCI > /proc/acpi/wakeup


You can still use it as follows, because the user's shell handles the quoted argument anyway:



sudo /bin/sh -c 'echo XHCI > /proc/acpi/wakeup'


You could also consider putting a complex command into a script, as suggested in a comment. https://serverfault.com/a/516002






share|improve this answer















edit: Warning, it appears that sudo does not safely handle spaces in the command, so it is not safe to use sudo in this way. https://unix.stackexchange.com/a/279142/39281



Instead of using quotes in the sudoers file, you can escape spaces using backslash:



%sudo ALL=(ALL) NOPASSWD: /bin/sh -c echo XHCI > /proc/acpi/wakeup


You can still use it as follows, because the user's shell handles the quoted argument anyway:



sudo /bin/sh -c 'echo XHCI > /proc/acpi/wakeup'


You could also consider putting a complex command into a script, as suggested in a comment. https://serverfault.com/a/516002







share|improve this answer















share|improve this answer



share|improve this answer








edited May 9 at 7:55


























answered May 9 at 6:40









Sam Watkins

1036




1036











  • This appears semantically identical to not having backslashes (that is, the arguments can still be grouped with quotation marks in every possible arrangement).
    – Ryan Lue
    May 9 at 7:03










  • Someone commented: there's an other QA telling this is possibly unsafe: unix.stackexchange.com/questions/279125/… then removed their comment. But they were right, it is unsafe, seems like sudo is not safe to be used when there are spaces in the command name. Perhaps I am misusing it, or perhaps it is a rubbish insecure tool. If it is so easy to misuse, I suggest the latter.
    – Sam Watkins
    May 9 at 7:53
















  • This appears semantically identical to not having backslashes (that is, the arguments can still be grouped with quotation marks in every possible arrangement).
    – Ryan Lue
    May 9 at 7:03










  • Someone commented: there's an other QA telling this is possibly unsafe: unix.stackexchange.com/questions/279125/… then removed their comment. But they were right, it is unsafe, seems like sudo is not safe to be used when there are spaces in the command name. Perhaps I am misusing it, or perhaps it is a rubbish insecure tool. If it is so easy to misuse, I suggest the latter.
    – Sam Watkins
    May 9 at 7:53















This appears semantically identical to not having backslashes (that is, the arguments can still be grouped with quotation marks in every possible arrangement).
– Ryan Lue
May 9 at 7:03




This appears semantically identical to not having backslashes (that is, the arguments can still be grouped with quotation marks in every possible arrangement).
– Ryan Lue
May 9 at 7:03












Someone commented: there's an other QA telling this is possibly unsafe: unix.stackexchange.com/questions/279125/… then removed their comment. But they were right, it is unsafe, seems like sudo is not safe to be used when there are spaces in the command name. Perhaps I am misusing it, or perhaps it is a rubbish insecure tool. If it is so easy to misuse, I suggest the latter.
– Sam Watkins
May 9 at 7:53




Someone commented: there's an other QA telling this is possibly unsafe: unix.stackexchange.com/questions/279125/… then removed their comment. But they were right, it is unsafe, seems like sudo is not safe to be used when there are spaces in the command name. Perhaps I am misusing it, or perhaps it is a rubbish insecure tool. If it is so easy to misuse, I suggest the latter.
– Sam Watkins
May 9 at 7:53












 

draft saved


draft discarded


























 


draft saved


draft discarded














StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f442671%2fspecify-command-with-quoted-arguments-in-sudoers%23new-answer', 'question_page');

);

Post as a guest













































































Popular posts from this blog

How to check contact read email or not when send email to Individual?

Bahrain

Postfix configuration issue with fips on centos 7; mailgun relay