1

I have a specific problem. Here's a simplified example:

File /opt/test is owned by root. Has file permissions of 700.

I need to cp /opt/test /home/user/.

So I need this exact command set in my sudoers file. I can't open up permissions to any other command.

But if I put this as a NOPASSWD command in /etc/sudoers it doesn't work because my user does not have permissions to see /opt/test before it su's to the root user (sudo is 'globbing' or whatever the file paths before it runs an su to root).

How can I invoke this command in a subshell or something so that I can get the exact command laid out in /etc/sudoers? Putting the command in a script and then laying out the path to the script in sudoers fails (permissions). I think I need to invoke a subshell of sorts, but don't know how to lay that out in sudoers.

John Kugelman
  • 349,597
  • 67
  • 533
  • 578
jasonmclose
  • 1,667
  • 4
  • 22
  • 38
  • I don't understand the problem you're having. Can you copy and paste terminal output showing what's happening, and show us exactly what you entered into `/etc/sudoers`? Your diagnosis doesn't really make sense to me: "...my user does not have permission to see `/opt/test` before it `su`'s to the root user". If you do it right and grant access to `cp /opt/test /home/user/` then `sudo cp /opt/test /home/user/` will work. – John Kugelman Jan 22 '19 at 18:19
  • This doesn't seem to be a question about programming. – yole Jan 22 '19 at 18:24
  • Sure. If I put `cp /opt/test /home/user` in my sudoers file as NOPASSWD for my user, it fails and tells me permission denied. I don't know if this is because sudo is first trying to test and make sure the files exist before it changes UID and then passes the files to `cp`, but I think that is what is happening. Basically, similar to what is explained here: https://superuser.com/questions/918333/why-cant-sudo-cp-find-the-files – jasonmclose Jan 22 '19 at 18:46
  • The question you linked has globs `*`. Yours doesn't, so the answer doesn't apply. – John Kugelman Jan 22 '19 at 19:25
  • So we dug and dug and figured out the problem(s). First, the 'to' destination was a network mount with nosuid set, and that was causing problems with sudo. Second, SELinux contexts were set on the 'from', & it was blocking access to stat the files for reading. So if anyone else has a similar problem, try checking your mount permissions and SELinux policies. – jasonmclose Jan 23 '19 at 13:39

0 Answers0