running as another user?

[Joshua ChaitinPollak]

On Jan 20, 2006, at 12:30 PM, Rob Landley wrote:

> On Thursday 19 January 2006 20:26, Paul Fox wrote:
>
>>> Or, to show that -c is pointless:
>>>   su root /bin/sh \-c "ls -l"
>>>
>>> Unfortunately, you need the - to prevent getopt from parsing -c  
>>> as an
>>> option to su.  (Maybe this is an ubuntu bug?)
>
> Obviously, that should have been "Unfortunately, you need the \ to..."
>
>> okay.  it turns out i don't understand su as well as i thought,
>> but i think i understand better now.  in a traditional version of
>> su (and i just checked a very old pre-SystemV AT&T manual) the -c
>> shouldn't ever be interpreted by su.  a correctly operating su
>> should pass all of its args to the shell.
>
> Why run a shell?  If you tell it an executable to run, why can't it  
> just exec
> the executable directly?  Your command line options are already  
> parsed, so
> theoretically all you have to do is execvp(argv[offset],argv+offset);
>
> Now if you don't specify a command, or if you start with an  
> unrecognized
> option (one other than -m, -p, or -s), then you need to stick a  
> shell in
> front of it.  (Both - and -c should be handled by your shell anyway.)
>
>> so this:
>>     su root ps ax
>> becomes this (after the id switch):
>>     /bin/sh ps ax
>> which is where the "cannot execute binary file" comes from.
>
> Which busybox odes, but ubuntu doesn't.
>
>> to get around that error, you need to use:
>>     su root -c ps ax
>> which becomes:
>>     /bin/sh -c ps ax
>> note that the "-c" you added is an option to the shell, not to su.
>
> In the busybox version, -c requires quotes around "ps ax" or else  
> it will
> execute ps without ax.
>
>> but if i look at "man su" on ubuntu (which matches behavior with
>> what's in debian etch, though i don't have a man page there), i
>> see this text:
>>     Any arguments supplied after the username will be
>>     concatenated in a single command and passed to the invoked
>>     shell with the -c option of that shell.  If you want to
>>     provide separated arguments to the shell, you can supply exec
>>     <shell> <arguments> as the command.
>>
>> so in these newer su commands, su adds the "-c" for you.  and,
>> from experiment, it looks like it only passes one -c option, not
>> two, as you might expect from the man page.
>
> In low memory environments the ability to exec binaries without  
> going through
> a shell might actually be the behavior we want.  I'll have to think  
> about it.

Seems reasonable. Here's a question: How do environment variables fit  
into this with respect to launching a shell or not? For example, I'm  
currently doing:

su user -c "LD_LIBRARY_PATH=/my/libs /my/binary -myopts" > /tmp/ 
logfile &

Now, I know I could put the redirect into the quoted string and  
redirect as user rather than redirect as root, but I don't really  
care. I'd love to not spawn another shell though, but I'd still need  
to set the environment variable. Will this work?

LD_LIBRARY_PATH=/my/libs su user /my/binary -myopts > /tmp/logfile &

Does bb's su pass the environment into the executing application?

-- 
Joshua ChaitinPollak
Software Engineer
Kiva Systems