[SOLVED] How to source inside a sudo environment

grail · 06-28-2022, 10:46 AM

So I recently hit this issue at work and have discovered it is to do with the version of bash being run.
That being said, I need to find an alternative to get this option to work again.

The scenario is, I need to be able to source a file into my environment and then utilise the functions/variables that are from the sourced file.
So in bash v4.1:

Code:

$ sudo -u user cat /home/user/file
x=hello
$ sudo -u user -i bash -c '. file && set | grep hello && echo "#$x#"'
BASH_EXECUTION_STRING='. f1 && set | grep hello && echo "#$x#"'
SUDO_COMMAND='/bin/bash -c bash -c .\ f1\ &&\ set\ |\ grep\ hello\ &&\ echo\ "#$x#"'
x=hello
#hello#

Current version at work is 4.2+ and at home is 5.1.16, and they both produce this:

Code:

$ sudo -u user cat /home/user/file
x=hello
$ sudo -u user -i bash -c '. file && set | grep hello && echo "#$x#"'
BASH_EXECUTION_STRING='. f1 && set | grep hello && echo "##"'
SUDO_COMMAND='/bin/bash -c bash -c .\ f1\ &&\ set\ |\ grep\ hello\ &&\ echo\ "#$x#"'
x=hello
##

Now there are two things to note here:

1. The line after x=hello which is my echo'ed output (which should be #hello#)

2. If you look at the BASH_EXECUTION_STRING it has already expanded the $x to be nothing?? My understanding here is as the commands
being run are in single quotes the variable should not get expanded until after the login and see the exported variable

My understanding is this is probably some kind of security feature, however, is it possible at all to source a file once logged in
via sudo as a user and then recall the source'd material?

Please let me know if any additional information is required?

pan64 · 06-28-2022, 11:00 AM

in general it should work.
I would use full path, like this:

Code:

sudo -u user -i bash -c '. /home/user/file && set | grep hello && echo "#$x#"'

But as usual better to write a script containing everything you need and execute that with sudo.

grail · 06-28-2022, 11:22 AM

No different:

Code:

$ sudo -u user -i bash -c '. /home/user/f1 && set | grep hello && echo "#$x#"'
[sudo] password for grail:
BASH_EXECUTION_STRING='. /home/user/f1 && set | grep hello && echo "##"'
SUDO_COMMAND='/bin/bash -c bash -c .\ /home/user/f1\ &&\ set\ |\ grep\ hello\ &&\ echo\ "#$x#"'
x=hello
##

Not that I expected it to, but happy to test any option

As this is how we run many different commands on our system and with varying uses of the source'd material, it is less than practical to have a script for all of them

Also, the general feedback is, "Why did it just stop working?"

boughtonp · 06-28-2022, 11:35 AM

I'm not sure I understand, so this might not make sense, but since you're using Sudo to run Bash, can you not use either --rcfile or BASH_ENV to do this, as per https://www.gnu.org/software/bash/manual/html_node/Bash-Startup-Files.html ?

As for why it changed, if you've identified the version when it changed, you should be able to consult the relevant section of the bash changelog, then identify the relevant issue / commit message to find out the reason.

pan64 · 06-28-2022, 11:36 AM

So it was working. If I remember well there were some incompatible changes around bash 4.2, but I can't recall it (which was probably related to it).
You might want to escape that $ sign anyway.

grail · 06-28-2022, 11:46 AM

@pan64 --- yep tried with escaping, still no change

@boughtonp --- whilst you are correct that shifting some into .bash_profile can fix the issue, we also have a situation where the same variable gets over-written by source'ing a different
file, so this would only fix some of our issues and not the main issue as a whole

I will see if I can find the correct changelog, however, not sure this will change the outcome?

boughtonp · 06-28-2022, 11:58 AM

Quote:

Originally Posted by grail

I will see if I can find the correct changelog, however, not sure this will change the outcome?

Depends on the reason for the change - it may involve a comment such as "disable insecure X; correct method is Y" or whatever.

Also a chance it's not mentioned because it's an unintentional change (i.e. a bug), though that seems less likely given how old 4.2 is.

ntubski · 06-28-2022, 10:13 PM

I futzed around for a bit, and found that ${x} seems to work, even though $x doesn't!? Also, I suspect this might be a difference in sudo rather than bash (I don't have an older bash handy, but the difference seems to show up with just printf too):

Code:

$ sudo -u $USER -i bash -c '. f1 && set | grep hello && echo "#$x#${x}#"'
BASH_EXECUTION_STRING='. f1 && set | grep hello && echo "##${x}#"'
SUDO_COMMAND='/bin/bash -c bash -c .\ f1\ &&\ set\ |\ grep\ hello\ &&\ echo\ "#$x#${x}#"'
x=hello
##hello#
$ sudo -u $USER -i /usr/bin/printf '[%s]\n' '${x}' aa '#$x#'
[${x}]
[aa]
[##]
$ bash --version
GNU bash, version 5.0.3(1)-release (x86_64-pc-linux-gnu)
Copyright (C) 2019 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>

This is free software; you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
vpsuser720@vpsuser-720:~$ sudo --version
Sudo version 1.8.27
Sudoers policy plugin version 1.8.27
Sudoers file grammar version 46
Sudoers I/O plugin version 1.8.27

grail · 06-28-2022, 11:20 PM

ntubski for the win

Of all the tests I didn't think to try <doh>

Well I know some of my team mates will be less than happy as they already dread sudo with a passion, but adding curly braces definitely saves
me a lot of time

Thanks again ... as usual, still love this community after all this time

pan64 · 06-29-2022, 12:50 AM

Quote:

Originally Posted by ntubski

I futzed around for a bit, and found that ${x} seems to work, even though $x doesn't!? Also, I suspect this might be a difference in sudo rather than bash (I don't have an older bash handy, but the difference seems to show up with just printf too):

Very good. From my side I think it is related to bash, how it evaluates this command line and that had been "slightly" changed between 4.1 and 4.3. Unfortunately I can't find the relevant info and also I can't test it, but anyway you found it.

NevemTeve · 06-29-2022, 01:09 AM

Edit: It might have something to do with the -i option of sudo:

Code:

$ sudo -u $USER bash -c 'x=hello; echo "#$x#${x}#"'
#hello#hello#

$ sudo -u $USER -i bash -c 'x=hello; echo "#$x#${x}#"'
##hello#

Edit: if either -i or -s is specified, sudo does something different than otherwise. That can be proved via `strace` (running as root).

Code:

$ strace -f -s 2048 sudo -u zsiga  -i ksh -c 'x=hello; echo "#$x#${x}#"' 2>ki.x
execve("/bin/bash", ["-bash", "--login", "-c", "ksh -c x\\=hello\\;\\ echo\\ \\\"\\#$x\\#$\\{x\\}\\#\\\""]

$ strace -f -s 2048 sudo -u zsiga ksh -c 'x=hello; echo "#$x#${x}#"' 2>ki.y
execve("/usr/bin/ksh", ["ksh", "-c", "x=hello; echo \"#$x#${x}#\""]

grail · 06-29-2022, 04:14 AM

@NevemTeve --- The -i is a requirement as the user's environment also sets many other options which are also required, in addition to the source'd material. Also, as advised initially, this all works with lower version of bash / sudo

NevemTeve · 06-29-2022, 04:34 AM

I've just tested it with sudo-1.9.11p3, same effect.

Now I think it is a version of 'shell quoting hell' let's name it 'sudo quoting hell'

ntubski · 06-29-2022, 04:45 AM

Quote:

Originally Posted by NevemTeve

Edit: if either -i or -s is specified, sudo does something different than otherwise. That can be proved via `strace` (running as root).

Code:

$ strace -f -s 2048 sudo -u zsiga  -i ksh -c 'x=hello; echo "#$x#${x}#"' 2>ki.x
execve("/bin/bash", ["-bash", "--login", "-c", "ksh -c x\\=hello\\;\\ echo\\ \\\"\\#$x\\#$\\{x\\}\\#\\\""]

Aha, so sudo is escaping "{}" but not "$" for the login shell. That seems wrong, but it could be intensional.

NevemTeve · 06-29-2022, 05:45 AM

This take us back to square 1: "use a script instead"