help-bash
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Help-bash] Root access in subshell


From: Richard Taubo
Subject: Re: [Help-bash] Root access in subshell
Date: Tue, 4 Feb 2014 00:34:50 +0100

On Feb 3, 2014, at 8:01 AM, Bob Proulx <address@hidden> wrote:

> Richard Taubo wrote:
>> Greg Wooledge wrote:
>>> Richard Taubo wrote:
>>>> I am running the following command in the terminal logged in as root (not 
>>>> via a script):
>>>>    [#] $(find / -user myuser)      # This is a part of a little larger 
>>>> script
> 
> Is that "[#]" your prompt?  It is hard to tell.
Yes.

>  If so are you
> actually running the subshell and then running the result of the
> subshell?  That doesn't make any sense.

I was actually trying to do the following (using $ as the prompt):
$ OldIFS=$IFS; IFS=$'\n'; \
for i in $(cat /etc/passwd); do \
split_word=":"; my_user="${i%%$split_word*}";\
if [[ "$my_user" != "root" && "$my_user" != “bin" ]]; then \
printf "%s\n" "------- Finding files by user: $my_user";\
find / -user $my_user -not -path "/proc/*" -print -quit;\
fi;\
done;\
IFS=$OldIFS;

Earlier I SHOULD have either set the sub command to a variable,
or dropped it altogether as I did above.


> 
>> I made the error of thinking that the subshell would return the
>> result directly to the main shell, so I was confusing the lack of
>> returned feedback with that the subshell was not run as root.  I saw
>> that error messages came from the subshell, but not the result of
>> the command itself, and was taken for a spin . . .
> 
> When you use $(...) it runs the command and replaces the output on the
> command line and runs the result.  So the result is data dependent.
> And could be dangerous!  If the first command found is "rm" then it
> would run rm with the rest of the arguments.  But that would be
> unlucky.  Probably it will run some other command and fail.  If the
> first file is "." then it will try to source the first file.
> 
>  $ mkdir /tmp/test
>  $ cd /tmp/test
>  $ date > foo
>  $ date > bar
>  $ find . -print
>  .
>  ./bar
>  ./foo
>  $ cat foo
>  Sun Feb  2 23:58:40 MST 2014
>  $ $(find . -print)
>  bash: Sun: command not found
> 
> But it might not say anything at all.
> 
>  $ echo echo foo > foo
>  $ cat foo
>  echo foo
> 
> And therefore:
> 
>  $ $(find . -print)
>  foo
> 
> That is because 
> 
>  $ echo $(find . -print)
>  . ./bar ./foo
> 
> And it will source ./bar which just contains "echo foo" which it does
> and therefore no error.
> 
> Using $(...) is really just for assigning to variable or for placement
> on the commandline.
> 
>> I see that if the subshell is set to a variable I can return 
>> the feedback to the main shell — are there other ways to return such
>> feedback to the main shell?
> 
> Huh?  What you are saying makes no sense to me.  What are you saying?
> Returning feedback?  Simply run the command.  The output will be
> printed.  Why are you using $(...) there?
As I mentioned in an earlier mail, I meant return the RESULT.
Using $(…) was a mistake; I should have done something similar to above and 
dropped the subshell.


Thanks for your extended explanation! :-)

Best regards,
Richard Taubo




reply via email to

[Prev in Thread] Current Thread [Next in Thread]