How to autostart a graphical application as a different user on a Debian linux distribution for a non-privileged user?

Question

linux

Actually, what I need to achieve from Debian:

• there is a graphical application that needs permission to change a couple of system configs in /etc/;
  
• there is a reader user (in fact, a guest user), whose rights should be as limited as possible;
  
• the graphical application should start automatically when the reader user logs in.
  

Running a graphical application as root may be redundant, but acceptable.
Running as a separate user and adding him the rights to edit that pair of system configs seems to be more optimal.
In any case, the graphical application should be automatically launched for the guest user by default (maximum without rights), but with the rights of another user.
How can this be implemented?
I would be glad for advice on the matter.
UPDATE
Two users have been created: reader and defender
The defender user has been added to the root group, and group access rights have been changed for the necessary configs.
The graphic application is written in "python gtk3". As I understand it, suid is not suitable for running .py and .sh script files.
Wrapped the command to run in bash-script:

cd /home/defender/thin-defender/thin_defender
/home/defender/thin-defender/.venv/bin/python3 /home/defender/thin-defender/thin_defender/manage.py run_app --config test

Added the following rule to sudoers before include:

reader  ALL=(ALL:ALL) NOPASSWD:/home/defender/thin-defender/thin_defender/run.sh

Run through

sudo -u defender /home/defender/thin-defender/thin_defender/run.sh

...not working as expected:

No protocol specified
Unable to init server: Could not connect: Connection refused
No protocol specified
Unable to init server: Не удалось подключиться к: Connection refused
Segmentation fault

Run through

gksudo -u defender /home/defender/thin-defender/thin_defender/run.sh

Gives nothing.
Added the d key to get debug information:

No ask_pass set, using default!
xauth: /tmp/libgksu-4YNi0X/.Xauthority
STARTUP_ID: gksudo/|home|defender|thin-defender|thin_defender|run.sh/3546-0-default_TIME8935278
cmd[0]: /usr/bin/sudo
cmd[1]: -H
cmd[2]: -S
cmd[3]: -p
cmd[4]: GNOME_SUDO_PASS
cmd[5]: -u
cmd[6]: defender
cmd[7]: --
cmd[8]: /home/defender/thin-defender/thin_defender/run.sh
buffer: -No protocol specified-
buffer: -Unable to init server: Could not connect: Connection refused-
buffer: -No protocol specified-
buffer: -Unable to init server: Не удалось подключиться к: Connection refused-
buffer: --
buffer: --
buffer: --
buffer: --
buffer: --
buffer: --
buffer: --
buffer: --
buffer: --
buffer: --
buffer: --
buffer: --
buffer: --
buffer: --
buffer: --
buffer: --
buffer: -Segmentation fault-
buffer: --
buffer: --
buffer: --
buffer: --
buffer: --
buffer: --
buffer: --
buffer: --
buffer: --
buffer: --
buffer: --
buffer: --
buffer: --
buffer: --
buffer: --
buffer: --
buffer: --
buffer: --
buffer: --
buffer: --
buffer: --
buffer: --
buffer: --
buffer: --
buffer: --
buffer: --
buffer: --
buffer: --
buffer: --
brute force GNOME_SUDO_PASS ended...
No password prompt found; we'll assume we don't need a password.
xauth: /tmp/libgksu-4YNi0X/.Xauthority
xauth_env: /home/reader/.Xauthority
dir: /tmp/libgksu-4YNi0X

When using gksu with sudo as a backend (switch -S):

gksu -Sdu defender /home/defender/thin-defender/thin_defender/run.sh

The behavior is similar, in debugging the same errors.
And here is gksu in normal mode (i.e. su as backend):

gksu -du defender /home/defender/thin-defender/thin_defender/run.sh

Causes the defender user to ask for a password, which is not acceptable in my case. Although the application starts after entering the password.
Where and what config to edit in order to make a password-free call to a specific script through gksu in normal mode (without using a backend in the form of sudo) did not google.
I also tried adding to the bash script:

run xhost
export DISPLAY=":0.0"
xhost +

But there seemed to be no point.
Actually, I have not yet found a working solution for launching the application from another user without a password.

Answer 1

I studied this question: I took out an
orange (Orange PI One), filled it with armbian.
The easiest way is to take lightdm and run the application as greeter (no auto-logins needed).
In this version, you only need to install xorg and lightdm
and run systemctl set-default graphical.target
/etc/lightdm/lightdm.conf

[Seat:*]
greeter-session=my-greeter

/usr/share/xgreeters/my-greeter.desktop

[Desktop Entry]
Name=My GTK+ Greeter
Comment=This runs the My GTK+ greeter, it should only be run from LightDM
Exec=python /home/user/greeter.py
Type=Application
X-Ubuntu-Gettext-Domain=lightdm

the application will restart on exit, it is located in the 7th console, in the other consoles the login line will hang.
In general, any script can be run under the X from the lightdm user by default.
or you can just look for a ready-made greeter (login program) and run RDP through the session script.
You can get parameters via DHCP like this
/etc/dhcp/dhclient-exit-hooks.d/myparamscript

setup_add() {
    echo $new_host_name > /etc/hostname
    hostname $new_host_name

    if [ -z "$new_nds_servers" ] ; then
        return
    fi

    echo rdp_server=$new_nds_servers > /tmp/rdp_config
    echo rdp_user=$new_nds_tree_name >> /tmp/rdp_config
    echo rdp_passwd=$new_nds_context >> /tmp/rdp_config
}

case $reason in
    BOUND|RENEW|REBIND|REBOOT)
        setup_add
        ;;
    EXPIRE|FAIL|RELEASE|STOP)
        return
        ;;
esac

on the DHCP server, custom options are configured for each client:
nds_servers
nds_tree_name
nds_context

Answer 2

there is a graphical application that needs permission to change a couple of system configs in /etc/;

It is desirable to solve this problem. Why the hell would any "graphics application" need to write to /etc/? Him here Windows, or what?

Answer 3

gksu ?

Answer 4

man suid
Even Wikipedia has: https://ru.wikipedia.org/wiki/Suid
And if the script, then:
sudo cat /etc/sudoers
Everything is written right there in the comments.
Or google sudoers nopasswd

Answer 5

Running an application as root in a guest session is certainly powerful. If you really need it, look towards sudo

Answer 6

No "graphical application" from the user should write to directories other than home and /tmp. And getting into /etc is complete hell and demons. If you really need to change something like this in /etc - write a daemon that will start as root and write to /etc and a client that will send commands to it. And it’s best to start the demon not from root, but from some pseudo-user who will own this pair of files