3

I have a question about permissions.

Distro: Debian GNU/Linux 6.0.4 (squeeze)

So I have a folder with a php script in it. Both folder and file are owned by User1

If I do this:

php script.php

I get a permission denied error. Fair enough; I'm User2, not User1. If I do

sudo php script.php

this works because my user account is setup for that.

So I wrote this script to accept an optional argument to output some stuff, like a "debug" mode, so if I do this:

sudo php script.php debug

It outputs some stuff to CLI. So far so good.

But sometimes the output from the script is too long and I can't scroll up to see the output from the beginning, so I want to be able to redirect the output to a file.

So I have tried the following:

This gives me a permission denied error.

sudo php script.php debug >> results.txt

This works

sudo touch results.txt
sudo chown User1 results.txt
sudo chmod 777 results.txt
sudo php script.php debug >> results.txt

Alternatively, this works

sudo su -
php script.php debug >> results.txt

So what I want to know is... why did the first one give me a permission denied error? I thought the point of the sudo prefix is that I run the command as root, which works for running the php script...but it seems to me that this doesn't extend to executing the redirect? Can someone explain why?

EDIT:

So I found something from another post on here that works:

sudo php script.php debug | sudo tee results.txt

The answer there confirms my suspicion about the redirect still being run under my user and not sudo, but it doesn't explain why...can anybody explain why?

Community
  • 1
CrayonViolent
  • 133

1 Answers1

3

When working on a command line the shell first does the redirections and after that does the execve to the external command. This means that the redirections are performed with unchanged user rights (because the shell doesn't care about sudo getting involved later).

The sudo command which could easily do >> results.txt doesn't see that but just gets a changed file descriptor for /dev/stdout.

Two possibilities:

  1. You make the redirection to a file / directory which is writable to you (User2).
  2. You write a wrapper script which does that and call the wrapper script via sudo.
Hauke Laging
  • 90,279
  • 1
    Thanks, and I found this answer from another question here (edited my question to reflect). So I'll mark your answer, but I'm just curious..and I guess maybe this is a question of philosophy or something..but do you know why sudo doesn't extend to the redirect? Seems to me it logically should...but I'm sort of a noob at CLI so maybe (likely) I'm not seeing the bigger picture – CrayonViolent Mar 15 '13 at 14:54
  • 2
    I already answered exactly that. >>file is a shell feature not a general feature thus is cannot be passed as an argument. The shell forks, redirects I/O and then tries to execute the external command. In your case the redirection fails thus calling sudo is not even tried. SUID rights are relevant only when e.g. files are opened. But most programs don't open /dev/stdout: They simply inherit it from their parent. So it's the parent's access rights which determine the possible redirections. – Hauke Laging Mar 15 '13 at 15:10
  • 2
    @CrayonViolent sudo doesn't see the redirect, it is handled by the shell. This design decisions allows redirection for any program without a need for modification/support by the program. – Ulrich Dangel Mar 15 '13 at 15:10
  • oh okay sorry, your additional explanations helped clarify it to me. thanks! – CrayonViolent Mar 15 '13 at 15:16