[PLUG] Backup problems (urgent)

[Micah Cowan]

1.  [rant] You should be true root for this to properly work.  Not

> "sudo" nonsense. A true root user can r/w anything to/from anywhere.
> Using sudo you are still in a user shell not a root shell.  This can
> prevent you from accessing various files.  IMHO, this is the greatest
> injustice that the *buntus and others have foisted onto the Linux
> public. [/rant]
>

I'm sorry, but that's just not true.

sudo does exactly what su does, with the following primary exceptions: (1)
it does more sophisticated authentication, and (2) runs the command given
as argument, instead of just always giving you a shell (su can be made to
run something other than shell too, with -c, but you still get the
simpler/dumber authentication of old su).

It's true that the shell under which sudo was run is still running under
the original user. Anything run under sudo, though (i,e., the thing
actually _doing_ anything) has full root privs (i.e., same situation as
su). sudo just "does" as root (or other user of your choosing). If you do
sudo cp -a ... the cp and its arguments are executed exactly as if they
were run under a root shell. Why tell people they "must" run a root shell
when all they need is that one command?

The only way you'd notice this "running under user shell" thing is if
you're trying to do something silly like "sudo cat foo > /some/place", in
which case of course the > isn't part of the sudo command at all, but is
evaluated under the same shell under which sudo runs (i.e., as a user). But
that's just a case of bad invocation, not a problem with sudo (the command
in that case should be sudo sh -c 'cat foo > /some/place', so the > is run
under sudo, and not the shell that ran sudo - otherwise it's the same as
doing "su -c 'cat foo' > /some/place" - in both cases, you're not letting
su[do] handle the >, with predictable results.

-mjc