Re: dchroot scripts
On Fri, Dec 17, 2004 at 05:29:01PM -0500, Kyle Rose wrote:
> cookedm+news@physics.mcmaster.ca (David M. Cooke) writes:
>
> > There are actually two separate problems with quoting in dchroot, and
> > they're both caused by interaction with su:
> >
> > Bug #249655: "dchroot -d ls -l" broken: su tries to interpret -l switch
> > * dchroot doesn't call su with -- before the command, so su tries to
> > interpret anything in the command that looks like one of it's options.
>
> Right: this is a definite dchroot problem.
I'd also call it an su problem: su shouldn't have any business trying to
interpret options after it's seen the username. The man page documents
it as 'su [OPTS] [-] [username [ARGS]]', not 'su [OPTS] [-] [username
and more opts and ARGS]'. (And -- isn't documented either). I should
file a bug...
> > Bug #276419: su appends the positional args to the command line
> > * Using su username command arg1 arg2, su calls sh -c with the string
> > "command arg1 arg2" using execv, instead of execvp. So spaces, etc.
> > screw you up. If it used execvp, you wouldn't have to do the quoting.
>
> ?? You mean it calls
>
> execv("/bin/sh", { "-c", "command arg1 arg2", 0 }) <--- you know what I mean
>
> ? Because that's what it *should* do. The only difference between
> this and execvp is that the "p" is for "path", as in PATH search. I
> think you're confused.
I was confused; I still want it to use execv, but not to strcat the
arguments together. It does do the above, as opposed to what I think is
better:
execv("/bin/sh", {"-c", "command", "arg1", "arg2", 0})
(which is also a valid way to call sh!). su _gets_ the arguments split
up like this; but it then strcats them together.
Basically, if you su like this (as dchroot does):
execv("/bin/su", {"username", "command", "arg1", "arg2", 0})
su then calls sh like you wrote. So the above is the exact same as
execv("/bin/su", {"username" "command arg1 arg2", 0})
... giving you *no* way to not have to quote the command and arguments.
> Besides, I'm guessing this won't be fixed in su: su's behavior in this
> regard is well-understood, and shouldn't be changed even if everyone
> agrees it's buggy. And I don't agree: sh -c "XYZ" should be
> equivalent (modulo different login files being loaded) to running sh
> and typing XYZ at the command line. This means you need to properly
> quote, which is what quote-args and quote-sh are for.
I don't have high hopes for fixing it in su either. Looking at the code
for su, at some point the behaviour I would like was planned or used!
The array for the arguments to pass to execv is allocated to be big
enough to hold the arguments split up. But, it then goes and strcat's
them together, wasting all that space it just allocated ...
It's a matter of _where_ you want (for instance) $variable to be
interpreted. You can argue it either way; my feeling is that when su
strcat's the arguments togther, it's going out of it's way to *lose*
information that was given to (how the arguments _were_ split apart,
which is vitally important when you've got spaces in filenames from an
ls *, for instance), which then the shell has to undo.
--
|>|\/|<
/--------------------------------------------------------------------------\
|David M. Cooke http://arbutus.physics.mcmaster.ca/dmc/
|cookedm@physics.mcmaster.ca
Reply to: