DietPi-Globals | Access for new sudo capable users

[MichaIng]

http://dietpi.com/phpbb/viewtopic.php?f=11&t=2796

The downside of moving aliases to dietpi-globals is, that they are by default just accessible for users root and dietpi, where we source them within ~/.bashrc.

Maybe there is an elegant way to grant access/source globals, as well as call /DietPi/dietpi/login for new sudo capable users automatically? Generally I like to adjust as few system files as possible/prefer to create our own addition files (conf.d etc.).

If I see right, /etc/bash.bashrc is sourced within /etc/profile and this allows additions within /etc/profile.d/. So e.g.:

cat << _EOF_ > /etc/profile.d/99-dietpi-login
. /DietPi/dietpi/func/dietpi-globals
/DietPi/dietpi/login
_EOF_

Should have the same effect as current ~/.bashrc, just automatically for all users.

[Fourdee]

@MichaIng

Most likely need to elevate to sudo aswell, else, non-root user will fail login script.
Unsure if globals will remain after sudo need to verify eg:

cat << _EOF_ > /etc/profile.d/99-dietpi-login.sh
. /DietPi/dietpi/func/dietpi-globals
sudo /DietPi/dietpi/login
_EOF_

[MichaIng]

@Fourdee

root@VM-Stretch:~# sudo source /DietPi/dietpi/func/dietpi-globals
sudo: source: command not found
root@VM-Stretch:~# sudo . /DietPi/dietpi/func/dietpi-globals
sudo: .: command not found

Sourcing is not possible via sudo.
However globals can be sources without sudo. Only downside is, that G_functions are available, that cannot be run without root privileges and sudo again does not know these functions:

micha@VM-Stretch:~$ sudo G_AGA
sudo: G_AGA: command not found
micha@VM-Stretch:~$ sudo -E G_AGA
sudo: G_AGA: command not found
micha@VM-Stretch:~$ G_AGA
[ INFO ] APT autoremove + purge, please wait...
tee: /var/tmp/dietpi/logs/dietpi-software_apt.log: Permission denied
E: Could not open lock file /var/lib/dpkg/lock - open (13: Permission denied)
E: Unable to lock the administration directory (/var/lib/dpkg/), are you root?
tail: cannot open '/var/tmp/dietpi/logs/dietpi-software_apt.log' for reading: Permission denied

There are some workarounds to access functions inside scripts with sudo, but they are ugly and unhandy. I think, if we really want to realize this for non-root users, then we would simply need to declare the affected functions inside a root privileges check statement, so they are simply hidden to non-root users. All our standalone dietpi scripts stay available via aliases also for sudo, just not the functions, declared within.

[Fourdee]

@MichaIng

I think, if we really want to realize this for non-root users, then we would simply need to declare the affected functions inside a root privileges check statement, so they are simply hidden to non-root users.

Sounds good 👍

I believe everything after G_CHECK_ROOT_USER, is root only (or should be). And all DietPi scripts, check for root during init, so we should be covered there aswell.

---

Other option, if we want to allow eg: sudo G_AGI moooooooo, add rootFS check to all functions, but yeah, I think for now your original idea is the solution. We can always tweak this in the future if needed.

micha@VM-Stretch:~$ sudo G_AGA
sudo: G_AGA: command not found

Ah, nevermind 🤣

sudo -E: https://stackoverflow.com/a/8633575

[MichaIng]

@Fourdee
Hehe, sudo -E did not work as well somehow 🤔, otherwise this would be great:

dietpi@VM-Stretch:~$ G_
G_AGA                      G_AGI                      G_AGUP                     G_CHECK_ROOT_USER          G_DIETPI-NOTIFY            G_FILE_EXISTS              G_OBTAIN_CPU_USAGE         G_TREESIZE
G_AGDUG                    G_AGP                      G_AG_CHECK_INSTALL_PREREQ  G_CHECK_URL                G_ERROR_HANDLER            G_INIT                     G_RPI_UPDATE               G_WHIP_MSG
G_AGF                      G_AGUG                     G_CHECK_ROOTFS_RW          G_DEV_1                    G_ERROR_HANDLER_RESET      G_OBTAIN_CPU_TEMP          G_RUN_CMD
dietpi@VM-Stretch:~$ sudo -E G_
G_AGA                      G_AGI                      G_AGUP                     G_CHECK_ROOT_USER          G_DIETPI-NOTIFY            G_FILE_EXISTS              G_OBTAIN_CPU_USAGE         G_TREESIZE
G_AGDUG                    G_AGP                      G_AG_CHECK_INSTALL_PREREQ  G_CHECK_URL                G_ERROR_HANDLER            G_INIT                     G_RPI_UPDATE               G_WHIP_MSG
G_AGF                      G_AGUG                     G_CHECK_ROOTFS_RW          G_DEV_1                    G_ERROR_HANDLER_RESET      G_OBTAIN_CPU_TEMP          G_RUN_CMD
dietpi@VM-Stretch:~$ sudo -E G_AGA
sudo: G_AGA: command not found
dietpi@VM-Stretch:~$ sudo -E G_DIETPI-NOTIFY 2 test
sudo: G_DIETPI-NOTIFY: command not found

Adding all of our globals to /etc/sudoers.d/ also sounds ugly to me, hmm okay if it is possible to just source globals inside, though an option... At least as far as I understood your link this would be necessary.

---

Besides:
I just played around with DietPi-Globals and DietPi-Login within /etc/profile.d/dietpi-login.sh. For now executing DietPi-Login via sudo is an easy solution and works quite well. What I don't like about it, is that also all Run_AutoStart and therefore all these software will be executed as root as well, which makes somehow the created non-root user useless. As far as I can see, all these can be started without root user, at least theoretically as desktops and games usually can 😉.
So I removed root user check and found just /DietPi/dietpi/func/obtain_network_details to cause problems, basically due to missing write access to /DietPi/dietpi/.. But some sudo rm and cat << _EOF_ | sudo tee "$file" > /dev/null worked well here.

Another issue, generally when running DietPi without root access, are scripts/functions, mainly G_ERROR_HANDLER (error handler log, dietpi apt log, some other flag files), writing as root some temporary .file, which can be than not removed/refreshed by non-root user. That is/was the same issue with the processing pid file, moreless solved via:
rm /tmp/dietpi-process.pid &> /dev/null || sudo rm /tmp/dietpi-process.pid &> /dev/null

But actually it would be extremely nice, if we could create such uncritical files, created by functions/scripts that reasonable do not need root privileges (G_DIETPI-NOTIFY/G_ERROR_HANDLER etc.) in a way, that all users can write and remove them, even without sudo. But I remember, experimenting with processing messages, that I couldn't find a place on file system, where root can create a file (even with chmod 777 afterwards) and non-root can remove it afterwards. That would need also write permissions to folder, which seems ordinary users do just have within their own home directory?

[MichaIng]

Note: /etc/profile(.d/) is not called on "non-login shells". By default, using screen does not open a login shell, thus profile(.d) is ignored. ~/.bashrc instead is called also by non-login shells. screen can be forced to open a login shell by:

cat << _EOF_ >> ~/.screenrc
shell -/bin/bash
_EOF_

Hah funny, ~/.screenrc is per-user again, so:

cat << _EOF_ >> /etc/screenrc
shell -/bin/bash
_EOF_

€: Note2: Actually wrong topic...

• Use /dev/shm/?

if [ ! -d /dev/shm/dietpi ]; then
    mkdir /dev/shm/dietpi
    chmod 777 /dev/shm/dietpi
fi
echo 'foo' > /dev/shm/dietpi/bar
chmod 777 /dev/shm/dietpi/bar

[Fourdee]

So one option:

• Do not sudo source the globals, probably a bad idea to allow users to run G_AGI etc, without sudo as per std linux.
• Run root user checks for the functions which require it

[MichaIng]

@Fourdee
We already had the idea so separate globals into non-root and root part, so only one root check is done, exiting the script, before G_AGX functions and other root depended ones are sourced.
sudo source/. is not possibly anyway 😉.

But difficult (for me) how to handle DietPi-Login on the long term. As sudo is no problem any more (did this somehow cause the other issue in combination with invalid $TERM? Was a bid confused as removing sudo indeed also solved it 🤔) we could of cause run it as sudo with all users, or at least in case $UID is not already 0. But I would like it, if we could reduce sudo to just the functions/autostarts that really need it to keep the (security) benefit of using a non-root user at all. obtain_network_details does definitely, but I am not sure about which autostart option does and which not.

[Fourdee]

@MichaIng

but I am not sure about which autostart option does and which not.

Me neither, I will need to go through them.
EDIT, pretty sure all of them require root for now, we'll need to debug/test each one as dietpi user at a later date.

Sudo proving impossible lol.

dietpi@DietPi:~$ G_AGI moo
[FAILED] Root privileges required. Please run the command with "sudo"

dietpi@DietPi:~$ sudo G_AGI moo
sudo: G_AGI: command not found

Interesting:

dietpi@DietPi:~$ sudo su
root@DietPi:/home/dietpi# G_AGI moo
bash: G_AGI: command not found

Dont believe we can export functions?

dietpi@DietPi:~$ export moo=true
dietpi@DietPi:~$ sudo -E echo $moo
true

[Fourdee]

dietpi@DietPi:~$ sudo bash -c '. /DietPi/dietpi/func/dietpi-globals; G_AGI moo'
[  OK  ] Root access verified.
[  OK  ] APT installation for: , please wait...

[  OK  ] G_AGI:
[  OK  ] APT installation for: moo, please wait...
E: Unable to locate package moo

[FAILED] G_AGI: moo

dietpi@DietPi:~$ alias sudo='sudo bash -c ". /DietPi/dietpi/func/dietpi-globals"; '
dietpi@DietPi:~$ G_AGI moo
[FAILED] Root privileges required. Please run the command with "sudo"

dietpi@DietPi:~$ sudo G_AGI moo
[FAILED] Root privileges required. Please run the command with "sudo"

[MichaIng]

@Fourdee

Dont believe we can export functions?

Jep, this also fits to my tests earlier. I think for this reason, skipping them for non-root users is the cleanest solution. Only thing that we could test is to add aliases (for non-root users only/instead) containing what you successfully tested above: alias G_AGI="sudo bash -c '. /DietPi/dietpi/func/dietpi-globals; G_AGI moo'"

[Fourdee]

https://www.sudo.ws/man/1.8.13/sudoers.man.html
As a special case, if sudo's -i option (initial login) is specified, sudoers will initialize the environment regardless of the value of env_reset. The DISPLAY, PATH and TERM variables remain unchanged; HOME, MAIL, SHELL, USER, and LOGNAME are set based on the target user. On AIX (and Linux systems without PAM), the contents of /etc/environment are also included. On BSD systems, if the use_loginclass flag is enabled, the path and setenv variables in /etc/login.conf are also applied. All other environment variables are removed.

Works, but we get relaunch of profile.d scripts.

Gah, logging in as another user uses sudo -i on profile.d due to our alias, cant check/exclude this in login script.
~Interesting that sudo is used by default to exec profile.d~ was running sudo for login script in profile.d

 2696 pts/1    S+     0:00 sudo -i /DietPi/dietpi/login

~alias sudo='sudo bash -c ". /DietPi/dietpi/func/dietpi-globals"; '~ is a no go.

Last resort, unfortunately is to manually add each entry we want to keep:

env_keep += "my_func=()*"

[Fourdee]

Ok so last 3 options are:

• 🈵 Manually define ENV we want to keep in sudoers, does not support keeping functions.
• 🈯️ G_SUDO with sudo -i
• 🈵 sudo -i alias, remove sudo from login profile.d launch. Too messy.

Also need to:

• Set RAMdisk to dietpi user by default
  -- DietPi user should always be the 1st user on system 1000. need to check across devices.

,uid=1000,gid=1000

setuid=value and setgid=value doesn't appear to be supported with tmpfs. So i dont believe we can preserve the permissions we set?

[Fourdee]

Ok, so I was unable to find a viable method of integrating our globals into sudo.
However, users can use sudo -i or G_SUDO to run our global commands.

We can only hope the user sees the message 1st:

dietpi@DietPi:~$ G_AGI moo
[FAILED] Root privileges required. Please run the command with "G_SUDO", or, "sudo -i".

---

To do:

• 🈯️ remove sudo from login, manually add sudo entries in for programs that require it.

[Fourdee]

Ok done.

@MichaIng

If I missed anything, please send me a nudge :)