bash - scope of exported functions

English Applications
1

Hello.

In /etc/profile.local, I source 2 bash files. One for exporting common env variables, one for exporting common bash function.
I am testing a program as super user ( declared in the wheel )
The program must be run as root and start with

(( EUID != 0 )) && exec sudo -- "$0" "$@"

Starting the program this way

sudo -E my_prog

give me access to environment variables which was exported, but not to exported functions.
Sudo seems to blocks it (As I saw by goggling) .

So I see some solutions :
1°) Run the program as root

su - root -c "my_prog"

give me access to environment variables which was exported, and to exported functions.

2°) Add code to source again the bash function file when program starts.
But the code is source twice.

3°) Source again the bash function file in my ~.profile.
But the code is source twice

Any help is welcome.

2

Does not work ?

3

I assume that “sudo” sanitizes the environment. Otherwise there can be security risks using an untrusted environment as root.

4

Like

su -

It is of course a security risk to run a process as user a in the environment of user b. Specially as user a is root.

To the OP. You at one point tell using sudo (to run processes ass owned by root) and later you give an alternative “Run the program as root” by using su -. I hope you understand that using sudo and su are just different ways of running processes as another user (often root).

5

I’ll rephrase the question :

I have two bash files , one for exporting common env variables, one for exporting common bash function.
I want that every logged user ( root, super user in the wheel, normal user ) has access to the exported variables and to the exported function when running their script.
So where to put these files to achieve this goal.
If possible without creating my own bash or my own operating system.

Any help is welcome.

6

What about /etc/profile.local?

henk@boven:/etc> head /etc/profile
# /etc/profile for SuSE Linux
#
# PLEASE DO NOT CHANGE /etc/profile. There are chances that your changes
# will be lost during system upgrades. Instead use /etc/profile.local for
# your local settings, favourite global aliases, VISUAL and EDITOR
# variables, etc ...

henk@boven:/etc>
7

That was the start of my question

Hello.

In /etc/profile.local, I source 2 bash files. One for exporting common env variables, one for exporting common bash function.
I am testing a program as super user ( declared in the wheel )
The program must be run as root and start with
Code:
(( EUID != 0 )) && exec sudo – “$0” “$@”
Starting the program this way
Code:
sudo -E my_prog
give me access to environment variables which was exported, but not to exported functions.
Sudo seems to blocks it (As I saw by goggling) .

8

What do you mean by:

I am testing a program as super user ( declared in the wheel )

What “wheel”? Where? I have the impression that you have a special environment created on your system. Which is of course your bussiness, but when you ask questions, you better explain extensive what you changed with respect to a fresh installed environment. Else you talk to deaf ears.

And I never use sudo (I only use su -l) thus I have no comment on that. But showing something instead of only talking theoretical might help others in understanding you. You seem to think (and I refer also to another thread of you) that everybody lives in the same pupa as you and that everybody thus understands immediately all of your environment and your goals when you just tell a minimal bit of where you got stuck in your quest.

9

>
>What do you mean by:
>
>What “wheel”? Where?
Please read :SDB:Administer with sudo - openSUSE Wiki

>I have the impression that you have a special environment created on your system.
Very common install. Nothing more

>And I never use sudo (I only use su -l) thus I have no comment on that.
So if like me you don’t know what sudo is for, you can’t help me.

>But showing something instead of only talking theoretical might help others in understanding you.
All is in the post #1 : bash - scope of exported functions

In /etc/profile.local, I source 2 bash files. One for exporting common env variables, one for exporting common bash function.
I am testing a program as super user ( declared in the wheel )
The program must be run as root and start with
Code:
(( EUID != 0 )) && exec sudo – “$0” “$@”
Starting the program this way
Code:
sudo -E my_prog
give me access to environment variables which was exported, but not to exported functions.
Sudo seems to blocks it (As I saw by goggling) .

**The goal **: In /etc/profile.local, I source 2 bash files. One for exporting common env variables, one for exporting common bash function.

The result : The running program cannot access exported function

**What I am doing **: I am testing a program as super user ( declared in the wheel ) …

**What could be specific : **The program must be run as root and start with …

> Originally Posted by hcvv https://forums.opensuse.org/images/buttons/viewpost-right.png](https://forums.opensuse.org/showthread.php?p=2810247#post2810247)
>What about /etc/profile.local?
>Code:
>henk@boven:/etc> head /etc/profile
># /etc/profile for SuSE Linux
>#
># PLEASE DO NOT CHANGE /etc/profile. There are chances that your changes
># will be lost during system upgrades. Instead use /etc/profile.local for
># your local settings, favourite global aliases, VISUAL and EDITOR
># variables, etc …
>henk@boven:/etc

In my question (see #1) I said that I have try this first.

10

You talk a lot, but show not much.

E.g. when you say “I source 2 bash files. One for exporting common env variables, one for exporting common bash function.”, that is what you think you do. But how can we check if you did it correct there when we do not see anything?

Showing computer facts makes your thread more trustworthy. Only telling stories makes your thread more suspicious. As another member once formulated it: We do not believe you, we believe computer facts.

BTW, as you say that the exported process environment variables are found, but that the exported functions are not. Could it be that you missed from

man bash

under INVOCATION:

If the shell is started with the effective user (group) id not equal to the real user (group) id, and the -p option is not supplied, no startup files are read, shell functions are not inherited from the environment, the SHELLOPTS, BASHOPTS, CDPATH, and GLOBIGNORE variables, if they appear in the environment, are ignored, and the effective user id is set to the real user id. If the -p option is supplied at invocation, the startup behavior is the same, but the effective user id is not reset.

(The bold is mine)

11

hello.

1°) /etc/profile.local

#!/bin/bash
#
####################
#                                    #
#                                    #
#    /etc/profile.local          #
#                                    #
#    §2016_12_16§             #
#                                    #
####################
#
#
# PLEASE DO NOT CHANGE /etc/profile. There are chances that your changes
# will be lost during system upgrades. Instead use /etc/profile.local for
# your local settings, favourite global aliases, VISUAL and EDITOR
# variables, etc ...
#
#
if test -z "$PROFILE_LOCAL_READ" ; then
   source /backup_sys/000_COMMON/Bin/system_common_general_env_var
   source /backup_sys/000_COMMON/Bin/system_common_function
/Bin/system_common_server_env_var"
    source /backup_sys/000_COMMON/Bin/system_common_server_env_var
#
   readonly PROFILE_LOCAL_READ=true
   export PROFILE_LOCAL_READ
fi
# For all users
export PATH=/backup_sys/000_COMMON/Bin:$PATH
#

2°) Program under test.

Must be run as root.

#!/bin/bash
#
##############################
#                                                        #
#                                                        #
#    ./script_test_as_root
#                                                        #
#                                                        #
##############################
#
# test a script run as root
#
########################################################
#
declare -i ERR_CODE
#
# ensure running as root
if  "$(id -u)" != "0" ]; then
   exec sudo "$0" "$@"
#
# or
# exec sudo -E "$0" "$@"
#

fi

#
if  -z $MY_HARDWARE ]] ; then
    echo "ERROR. SPECIFIC ENV VARIABLE NOT SET"
    echo "Exiting ..."
    exit 255
else
    echo "This computer is : $MY_HARDWARE"
fi

get_config_param_string "/etc/os-release" "PRETTY_NAME"
ERR_CODE=$?
if  $ERR_CODE -eq 0 ]] ; then
    OS_RELEASE=$RETURN_STRING
    if  "$OS_RELEASE" == "openSUSE Leap 42.2" ]] ; then
        echo "OK DOING FOR LEAP"
    else
        echo "NOTHING TO DO : NOT LEAP"
    fi
else
    echo "FINISHED WITH ERROR. ERROR CODE : $ERR_CODE"
    echo "Exiting ..."
    exit 255
fi

echo "FINISHED with SUCCESS"
exit 0

result Version 1 ( no -E in sudo )

user_test1@LINUX:~> ./script_test_as_root
root's password:
ERROR. SPECIFIC ENV VARIABLE NOT SET
Exiting ...
user_test1@LINUX:~>

result Version 2 ( with -E in sudo )

user_test1@LINUX:~> ./script_test_as_root
root's password:
MY_HARDWARE is : MY_SERVER
./script_test_as_root: line 30: get_config_param_string: command not found
FINISHED WITH ERROR. ERROR CODE : 127
Exiting ...
user_test1@LINUX:~>

In this version, the exported function (sourced in /etc/profile.local) are not accessible by user root. But the exported env variables (sourced in /etc/profile.local) are accessible by user root.

So it seems necessary to source the function definition also in /root/.profile and to use sudo -E.