I export LC_ALL="en_US.UTF-8" (via sendEnv in ssh_config) when using ssh to remote systems. When I su - user123 this variable is reset by the login shell. Is there a way to preserve this variable (as well as other LC_xxx variables) when executing a login shell as another user on the remote system? I realize I could export the variable by hand after executing the shell, or an entry in ~/.bashrc of the target user, however I'd rather try to preserve the original values as sent by ssh if possible. Thanks. **EDIT**: I do need specific parts of the user's environment initialized which is why su - is used. I would only want to preserve LC_xxx

I have centos7 as a virtual box on windows 7. Besides root, I created another user "john" during that time. Some time later, I forgot my root password and reset it my going to single user prompt. Since then whenever I login as "john" I am not able to do su -l root. I get permission denied. I logged in as root and changed sudoer file with the following: root ALL=(ALL) ALL admin ALL=/bin/su Defaults: admin rootpw john ALL=(ALL) ALL I then added john to wheel group and updated /etc/pam.d/su with: auth required pam_wheel.so use_uid Also,I am not able to do su -l john when I am logged in as "root". Any help here is appreciated. /var/log/secure shows: Mar 6 .... localhost su: PAM(other) no module name supplied Mar 6 .....localhost su: PAM(other) illegal module type: @include Mar 6 .....localhost su: PAM pam_parse: expecting return value: [...common-session] Manny

Doing this on a **RHEL8.10** distro. I've created a user with *staff_u* role: # useradd -Z staff_u testadm
And provided this user elevated permissions, for which did following steps:
1. created mysudoers file: /etc/sudoers.d/mysudoers 2. added this in it: %testadm ALL=(ALL) TYPE=sysadm_t ROLE=sysadm_r ALL
Did reboot. Installed my app's selinux policy module *(rpm)*. Then logged in with this *testadm* user, and ran this command to elevate to *sysadm_r:sysadm_t*: # sudo runcon -r sysadm_r -t sysadm_t -- su -
Now, on this console, with selinux **Enforcing**, I try running my application's executable (*maconfig*, which is internally running */etc/init.d/ma* which is my app's script) and I'm getting this permission denied error:

[root@6H0RHEL810 ~]# /opt/McAfee/agent/bin/maconfig -stop
2025-04-25 11:43:12.768 (50811.50811) maconfig.Info: Stopping Trellix agent.
sh: /etc/init.d/ma: /bin/sh: bad interpreter: Permission denied
2025-04-25 11:43:12.770 (50811.50811) maconfig.Info: configuration finished

So naturally, I looked for denials in */var/log/audit/audit.log* but got this kind of log instead:

type=SELINUX_ERR msg=audit(1745581392.769:2056): op=security_compute_sid invalid_context="staff_u:system_r:initrc_t:s0" scontext=staff_u:sysadm_r:sysadm_t:s0-s0:c0.c1023 tcontext=system_u:object_r:initrc_exec_t:s0 tclass=process
type=SYSCALL msg=audit(1745581392.769:2056): arch=c000003e syscall=59 success=no exit=-13 a0=5587d7a7b540 a1=5587d7a7c700 a2=5587d7a79e40 a3=0 items=0 ppid=50811 pid=50812 auid=1001 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts1 ses=8 comm="sh" exe="/usr/bin/bash" subj=staff_u:sysadm_r:sysadm_t:s0-s0:c0.c1023 key=(null)ARCH=x86_64 SYSCALL=execve AUID="testadm" UID="root" GID="root" EUID="root" SUID="root" FSUID="root" EGID="root" SGID="root" FSGID="root"
type=PROCTITLE msg=audit(1745581392.769:2056): proctitle=7368002D63002F6574632F696E69742E642F6D612073746F70

..which is not a straighforward avc denial. So searched for ways to tackle this.
Found the explanation for the log - a process running as sysadm_t (maconfig) tried to run a file labeled initrc_exec_t (*/etc/init.d/ma*), and SELinux said "nope" because it would result in an invalid context transition to initrc_t.
So tried a couple of other things: 1. Switched selinux to **Permissive** mode (setenforce 0), ran my app's command, it worked fine. Got some user_avc denials. Added rules in policy for allowing those, *but didn't work* after setenforce 1 again 2. Added this *domain transition* rule to my policy *(didn't work)*: domain_auto_trans(sysadm_t, initrc_exec_t, initrc_t); 3. Tried adding these **role-type statements** in policy (*which I thought would work for sure but nope*):

require {
	role system_r, sysadm_r;
    type initrc_t;
}
role system_r types initrc_t;
#AND
role sysadm_r types initrc_t;

4. Added this rule (didn't work): allow sysadm_t initrc_exec_t:process transition;
Also got to know some more stuff from these pages: - https://wiki.gentoo.org/wiki/SELinux/Tutorials/Linux_services_and_the_system_u_SELinux_user#:~:text=warrants%20proper%20control.-,Linux%20service%20scripts,-Most%20Linux%20service - https://github.com/SELinuxProject/selinux-notebook/blob/main/src/auditing.md#general-selinux-audit-events ..but still not sure how to proceed. Pls help out if u can. Thanks in advance!

I'm new to working with OS and unix, I'm trying to create separate users for an application, nginx, etc... and in order to run the process on their behalf. I'm currently debugging the following ways to run the command, and I can't figure out exactly what's really going on when using the runuser -u username and su username commands. **UPDATE** (thanks to @Kusalananda) Okay, what's wrong with permissions? root@someuser:/somehome# runuser -u app "source /etc/app/secrets/env; /somehome/way/app &" & 479621 root@someuser:/somehome# runuser: failed to execute source /etc/app/secrets/env; /somehome/way/app &: Permission denied ^C Exit 1 runuser -u app "source /etc/app/secrets/env; /somehome/way/app &" root@someuser:/somehome# root@someuser:/somehome# root@someuser:/somehome# ls -ld /etc/app/secrets/env -r-------- 1 app nogroup 1126 Apr 1 15:15 /etc/app/secrets/env root@someuser:/somehome# ls -ld /etc/app/secrets drwx------ 2 app nogroup 4096 Apr 1 15:15 /etc/app/secrets root@someuser:/somehome# ls -ld /somehome/way/app -rwxrw-r-- 1 app someuser 348528086 Mar 31 22:23 /somehome/way/app root@someuser:/somehome# ls -ld /somehome/way/ drwxr-xr-x 3 someuser someuser 4096 Apr 1 09:30 /somehome/way/ or i now trying to run like this: runuser --pty -u app -- bash "source /etc/app/secrets/env && /somehome/way/app &" bash: source /etc/app/secrets/env && /somehome/way/app &: Permission denied **The first(original question): Problem was $(), thanks to @Kusalananda** I want to point out that I consciously run, for example, a web application as a background process. Get to the point. I run applications/commands like this: runuser -u someapp $(source /etc/someapp/secrets/env; /someapp) su nginx source /etc/someapp/secrets/env && sleep 90s & **Eventually, I check ps aux or ps -A and see: app or the "sleep" commands are running as root!? What am I doing wrong? Or what I don't understand?** **P.S. But running this command i get what i expected:** runuser -u testappuser2 sleep 30s & #ps output root 462265 0.0 0.4 9376 4224 pts/1 S 18:20 0:00 runuser -u testappuser2 sleep 30s testapp+ 462270 0.0 0.1 5684 1920 pts/1 S 18:20 0:00 sleep 30s

I am trying to create a script that opens a new tmux session and then runs a command inside that tmux session as a different user. The purpose of this is to create a new tmux session for a game server, which has a different unix user assigned to it. I have heard that giving servers their own users was good practice, but I would still like to have a script in the home directory of my main user to start the server for convenience. **I would like the tmux session to be available from my main user, yet be logged in to the game server user.** The main problem is that there is a password prompt that I cannot get around, requiring me to attach to the tmux session, enter the password, and then detach. This is what I have tried:

#!/bin/sh

tmux new -d -s Minecraft sudo -u minecraft /home/minecraft/server/start.sh

I have tried every combination of running the script with sudo, adding su - Minecraft to the script, and su Minecraft -c "script", and in each one it either requires me to attach to the tmux session and login or just does not work, leaving no tmux session open. I am trying to find a solution which would allow me to type in my sudo password or the other user's password when I run the script which invokes tmux, instead of having to login by attaching and then detaching.

I want to switch to a different user, but loginctl shows that the previous user session is being used I start as the user ubuntu.

$ loginctl session-status | head -n1
2 - ubuntu (1000)

sudo su -l newuser # I even used the --login flag!! Which should LOG IN!

$ loginctl session-status | head -n1
2 - ubuntu (1000)

This affects things like lingering. **How do I switch to another user (without password), in a way that loginctl understands?** EDIT: For context, a service program running as that user is having issues, and I am trying to reproduce that environment in an interactive debugger. I worry that the login session is producing different behavior (specifically in regards to the linger user setting).

While administrating a linux server (a Debian server, for instance), I often switch users. Sometimes, I will chain multiple user switches together:

aluriak$ sudo -s
root$ […]
root$ su aluriak
aluriak$ […]
aluriak$ su db
db$ […]
db$ 
aluriak$ su front
front$ […]

Is there any way for me to get the "chain of users" I created that way? In the upper example, that hypothetical utility would output something along the lines of front aluriak root aluriak, because I am the front user, that logged in from aluriak user, that himself logged in from root account, that itself was reached from the aluriak account.

First of all what I want to do: I want to login to a server via ssh. Then change change the user via sudo su user and start some application on my screen. Some collegues do it by

su user
export DISPLAY=:0

an it works. --- I connect to a server via ssh -X user@server. Then I start a X11 application. This works fine (although there are warnings). Warnings: libEGL warning: DRI3: failed to query the version libEGL warning: DRI2: failed to authenticate qt.qpa.xcb: QXcbConnection: XCB error: 1 (BadRequest), sequence: 414, resource id: 1897, major code: 155 (Unknown), minor code: 1 --- If I run sudo su (or sudo su user) and start the program or run it via sudo myprogram there is an error. Error:

X11 connection rejected because of wrong authentication.
qt.qpa.xcb: could not connect to display localhost:11.0
qt.qpa.plugin: Could not load the Qt platform plugin "xcb" in "" even though it was found.
    This application failed to start because no Qt platform plugin could be initialized. Reinstalling the application may fix this problem.

Available platform plugins are: eglfs, linuxfb, minimal, minimalegl, offscreen, vnc, xcb.

Aborted

--- I found some articles about this problem. X11 forwarding fails when switching users ssh connection. X11 connection rejected because of wrong authentication --- So extend the /etc/pam.d/su file and the /etc/pam/sudo file by session optional pam_xauth.so And later I changed /etc/ssh/sshd_config by adding: X11Forwarding yes and restarting the sshd by systemctl restart ssh.service. ssh -T says x11forwarding yes But nothing changed. Does anybody know what to do? Its important to check some changes on the users program configurations after making changes.

I just stumbled upon a weird behavior on android: echo test>/data/local/tmp/test.txt su root -c "cat /data/local/tmp/test.txt && \ tar -cvzf /data/local/tmp/test.tar.gz /data/local/tmp/test.txt && \ echo $?" ls -alh /data/local/tmp/test.txt This will produce an empty test.tar.gz: test removing leading '/' from member names data/local/tmp/test.txt 0 -rw-r--r-- 1 root root 0 2025-01-09 17:43 /data/local/tmp/test.tar.gz Running without su root -c I will get a 120 byte tar.gz: -rw-r--r-- 1 root root 120 2025-01-09 17:47 /data/local/tmp/test.tar.gz Adding a sleep like this: su root -c "tar -cvzf /data/local/tmp/test.tar.gz /data/local/tmp/test.txt && sleep 1" Also produces a 120 byte tar.gz. *Update:* Doing this with a 50mb file, the tar subcommand blocks until it's finished and produces an invalid tar.gz which is short of 22031 bytes to a valid tar.gz produced without su -c $ ls -alh /system/apex/com.android.art.release.apex -rw-r--r-- 1 root root 54M 2009-01-01 00:00 /system/apex/com.android.art.release.apex $ tar -cvzf /data/local/tmp/big.tar.gz /system/apex/com.android.art.release.apex $ su root -c "tar -cvzf /data/local/tmp/bigsu.tar.gz /system/apex/com.android.art.release.apex" removing leading '/' from member names system/apex/com.android.art.release.apex $ ls -al /data/local/tmp/b* -rw-r--r-- 1 root root 22541839 2025-01-09 21:43 /data/local/tmp/big.tar.gz -rw-r--r-- 1 root root 22519808 2025-01-09 21:33 /data/local/tmp/bigsu.tar.gz $ tar -xvzf /data/local/tmp/bigsu.tar.gz /data/local/tmp/big.apex ; echo $? zcat: gzclose: Inappropriate ioctl for device tar: EOF: Illegal seek 1 $ tar -xvzf /data/local/tmp/big.tar.gz /data/local/tmp/big.apex ; echo $? 0 Same behavior when using another user besides root. This problem occurs on an android 11 emulator. I wasn't able to reproduce this on my linux servers. The only way I can explain it is that the write buffer from tar is not flushed to the emulated disk. A stat to the file inside the subcommand makes it flush the data correctly: $ su root -c "tar -cvzf /data/local/tmp/test.tar.gz /data/local/tmp/test.txt && stat /data/local/tmp/test.tar.gz" removing leading '/' from member names data/local/tmp/test.txt File: /data/local/tmp/test.tar.gz Size: 120 Blocks: 16 IO Blocks: 512 regular file Device: fd05h/64773d Inode: 65546 Links: 1 Device type: 0,0 Access: (0644/-rw-r--r--) Uid: ( 0/ root) Gid: ( 0/ root) Access: 2025-01-09 17:43:44.964000000 +0000 Modify: 2025-01-09 22:00:28.496000000 +0000 Change: 2025-01-09 22:00:28.496000000 +0000 $ ls -alh /data/local/tmp/test.tar.gz -rw-r--r-- 1 root root 120 2025-01-09 22:00 /data/local/tmp/test.tar.gz But why on earth would ending the subshell prevent flushing of the output file? When tar exits with a success exit 0, that means the written data should already be handled and flushed by the kernel. Simple copying does not have the flush problem. So it might be a tar bug. su root -c "cp /system/apex/com.android.art.release.apex>/data/local/tmp/release.apex" su root -c "cat /system/apex/com.android.art.release.apex>/data/local/tmp/releasecat.apex" ls -al /data/local/tmp/release* -rw-r--r-- 1 root root 56510850 2025-01-09 22:31 /data/local/tmp/release.apex -rw-r--r-- 1 root root 56510850 2025-01-09 22:33 /data/local/tmp/releasecat.apex The tar version of busybox does not have this problem! $ su root -c "/data/adb/magisk/busybox tar --version" tar (busybox) 1.36.1-Magisk $ su root -c "/data/adb/magisk/busybox tar -cvzf /data/local/tmp/test.tar.gz /data/local/tmp/test.txt" $ ls -alh /data/local/tmp/test.tar.gz -rw-r--r-- 1 root root 120 2025-01-09 22:42 /data/local/tmp/test.tar.gz *Notes:* - tar version toybox 0.8.3-android - same when using /sdcard/Download as a directory.

If the environment variable DISPLAY is set and I do `/bin/su - root` from a user shell in an X terminal, then a login shell for root is setup and the DISPLAY environment variable is still present. If I do `/usr/bin/systemd-run --quiet --setenv DISPLAY -t /bin/bash -c 'echo "DISPLAY is ${DISPLAY}" ; export DISPLAY=${DISPLAY} ; DISPLAY=${DISPLAY} /bin/su - root'` [Yes having both the export and the DISPLAY= before the command is probably overkill.] then when the login shell for root arrives, the DISPLAY environmental variable is not set, even though it was present and correctly echoed from the systemd-run process before the shell started up. (And I have tried doing --setenv DISPLAY=some_other_value just to check that a distinct value is being passed.) Testing the complicated `/bin/bash -c 'echo "DISPLAY is ${DISPLAY}" ; export DISPLAY=${DISPLAY} ; DISPLAY=${DISPLAY} /bin/su - root'` on its own just to check that starting the /bin/su -root from a bash command works, the display environmental variable is present in the root login shell. Omitting the bash invocation and just using /bin/su with the systemd-run command does not work and I include the bash invocation because of the answer to the earlier question systemd-run does not set environment variables when using --setenv So why is the DISPLAY not kept when the su login shell is started from systemd-run even though it has been correctly passed to the systemd-run environment with the setenv parameter? For reference, this is on openSUSE Leap 15.6 with systemd 254 (254.20+suse.113.gf7f6a3454e).

On the X desktop, I ocassionally used gksudo or just sudo somegui to launch GUI applications as another user, including root. I recently discovered that this is not possible on contemporary (early 2018) Wayland desktops. All applications must launch as the current desktop user, and are limited to the privileges of that user. Is this a permanent feature of Wayland (there by design), or is su-type usage an enhancement that has not yet been implemented? *I'm looking for a documented statement (roadmap, design page...), not preference or opinion.*

On a SLES 15 SP1 system, I've added a user to the wheel group:

wheel:x:1003:joeuser

however, when joeuser logs in as themselves, then tries to su (to become root), they are asked for their password. Why could that be happening? Here is /etc/pam.d/su:

#%PAM-1.0
auth     sufficient     pam_wheel.so trust
auth     sufficient     pam_rootok.so
auth     include        common-auth
account  sufficient     pam_rootok.so
account  include        common-account
password include        common-password
session  include        common-session
session  optional       pam_xauth.so

In my new Gentoo installation, su doesn't work as my non-root user: After entering the correct password I get the message "su: Permission denied". What could be causing this? I have already tried reinstalling the package containng /bin/su. EDIT: sudo works.

I have a question regarding the processes launched via a SSH session, after having performed a su - user. My question applies to RHEL 8, but might as well to other O/S. The SSH connection is initiated from a Windows machine, but the behavior is the same when initiating a SSH connection from any other means. The use case is the following: - log as user via SSH - perform

sudo su -

to switch to root - execute sleep 3000 - kill your SSH terminal (like close the mobaxterm window) In this case, the process sleep 3000 keeps running. This is not specific to the root user. If I switch to the activemq user with su - activemq, I have the same behavior. However, if I run the command sleep 3000 from the user I used to connect via SSH without performing the su -, killing the SSH terminal also kills the process, as expected. Is this an expected behavior? And is there a way for this to prevent happening ?

I am having trouble determining why su doesn't behave as the PAM configuration would imply. In short, using su to become another user should load secondary groups according to PAM configuration, but pam_group isn't adding the /etc/security/group.conf groups, we only end up with our LDAP groups. When logging in via SSH as a user, you have groups from both sources. Our setup is not too far from default CentOS 6.5, we're using SSSD to provide logins via Kerberos / LDAP but have not made direct changes to anything in /etc/pam.d as far as I recall, the changes were made by : authconfig --updateall --enablesssd --enablesssdauth --enablemkhomedir There are of course separate /etc/pam.d/su and /etc/pam.d/sshd, but they both include identical files where pam_group.so is called (including system-auth and password-auth respectively, but those two included files are identical). The relevant section of /etc/pam.d/su: #%PAM-1.0 auth sufficient pam_rootok.so auth include system-auth The relevant section of /etc/pam.d/sshd: #%PAM-1.0 auth required pam_sepermit.so auth include password-auth In the included file: #%PAM-1.0 # This file is auto-generated. # User changes will be destroyed the next time authconfig is run. auth required pam_env.so auth optional pam_group.so auth sufficient pam_unix.so nullok try_first_pass auth requisite pam_succeed_if.so uid >= 500 quiet auth sufficient pam_sss.so use_first_pass auth required pam_deny.so ... When logging in via SSH, the pam_group.so line adds groups via /etc/security/group.conf, adding 'apache' group (among others) to anyone who logs in: *;*;*;Al0000-2400;apache,devs,rvm When running su - username as root (or sudo su - ... as anyone else), and becoming another user, this pam_group does not appear to add these additional groups. In fact, where logging in as root gives you these groups (because pam_group did it's job), running su - username results in you losing those groups, because su starts from nothing and only adds in the groups it gets from PAM (LDAP groups essentially, since pam_group isn't working) Here you can see, logged in as root initially, I have apache (48), devs (501), and rvm (504), but running just su - to login as root I lose everything but root (0). Further, logging in as user 'bob' using su - bob you can see I have a lot of groups from LDAP (plus one hardcoded group from /etc/group that does work), but nothing from /etc/security/group.conf. [root@dev-web pam.d]# id -G 0 48 501 504 [root@dev-web pam.d]# su - [root@dev-web ~]# id -G 0 [root@dev-web ~]# logout [root@dev-web pam.d]# su - bob [bob@dev-web ~]$ id -G 1005001 10 1001000 1001001 1001002 1001003 1001004 1001005 1001008 1001009 1001010 1001011 1001012 1001017 1001018 1001025 1001027 1001028 1001033 1001034 Finally, what a SSH login as bob looks like - again I have apache (48), devs (501), and rvm (504). [bob@dev-web ~]$ id -G 1005001 10 48 501 504 1001000 1001001 1001002 1001003 1001004 1001005 1001008 1001009 1001010 1001011 1001012 1001017 1001018 1001025 1001027 1001028 1001033 1001034 One might assume the difference between su - username and logging in with SSH is that in the SSH case there is a password available for the various modules that use try_first_pass and so on, but since we often are logging in using Kerberos there's no password for these modules. I'll provide any further information (within reason) if it will help diagnose this discrepancy. Thanks in advance! edit: I have turned on PAM debugging and pam_group doesn't appear to fire for su - even if I disable pam_rootok so I have to log in (to make sure it actually tried to go through the rest of the pam stack). Regardless of where it is in the stack, other items fire (once pam_rootok is disabled, since it's "sufficient" status seems to short circuit the stack). Also it only occurred to me to test sudo, and it seems to have nearly the same problem. Root can sudo to itself and keep groups, but sudoing to another user only gets LDAP groups. /etc/pam.d/sudo just includes /etc/pam.d/system-auth which is the same stack su uses, so that shouldn't be a surprise. I suppose sudo is smart enough to not actually drop permissions / switch user if the target user is the same as current user, hence root keeping groups.

I recently switched from Windows to Linux, more specifically to Debian 12. I'm struggling a bit because there are a lot of new things, like sudo. Anyway, I'm basically trying to put my regular user as sudo, to facilitate development issues and not have to register as a super user for everything. I used the command gpasswd -a user sami and in fact it added the user as sudo, if I use groups sami, my user appears as sudo. However, if I try to use su sami and then enter my password correctly, it simply gives no error and nothing happens. If I enter the wrong password it gives me an authentication error. As expected, if I use apt update, without root, it gives a permission denied error. But the strangest thing is that if I type sudo apt install any_package_here or sudo apt update and enter my password, it normally installs the package or update the packages. Can anyone help me? Example of the Konsole.

sami@sami-debian:~$ su sami
Senha: 
sami@sami-debian:~$ # I entered the correctly pwd
sami@sami-debian:~$ su sami
Senha: 
su: Falha de autenticação
sami@sami-debian:~$ # I entered the wrong pwd and gave me auth failed
sami@sami-debian:~$ apt update
Lendo listas de pacotes... Pronto
E: Não foi possível abrir arquivo de trava /var/lib/apt/lists/lock - open (13: Permissão negada)
E: Impossível criar acesso exclusivo ao directório /var/lib/apt/lists/
W: Problema ao remover o link do ficheiro /var/cache/apt/pkgcache.bin - RemoveCaches (13: Permissão negada)
W: Problema ao remover o link do ficheiro /var/cache/apt/srcpkgcache.bin - RemoveCaches (13: Permissão negada)
sami@sami-debian:~$ # It's in portuguese, but basically says permission denied for everything
sami@sami-debian:~$ sudo apt install 7zip
Lendo listas de pacotes... Pronto
Construindo árvore de dependências... Pronto
Lendo informação de estado... Pronto        
Os seguintes pacotes foram instalados automaticamente e já não são necessários:
  libdaxctl1 libndctl6 libpmem1 liburing2
Utilize 'sudo apt autoremove' para os remover.
Os NOVOS pacotes a seguir serão instalados:
  7zip
0 pacotes atualizados, 1 pacotes novos instalados, 0 a serem removidos e 0 não atualizados.
É preciso baixar 0 B/976 kB de arquivos.
Depois desta operação, 2.662 kB adicionais de espaço em disco serão usados.
A seleccionar pacote anteriormente não seleccionado 7zip.
(Lendo banco de dados ... 195927 ficheiros e diretórios atualmente instalados.)
A preparar para desempacotar .../7zip_22.01+dfsg-8_amd64.deb ...
A descompactar 7zip (22.01+dfsg-8) ...
Configurando 7zip (22.01+dfsg-8) ...
A processar 'triggers' para man-db (2.11.2-2) ...
sami@sami-debian:~$ # It didn't ask for a password, and I have no idea why, but installed correctly the package
sami@sami-debian:~$ su
Senha:
root@sami-debian:~$ # I entered correctly password for root user and worked as expected

sami@sami-debian:~$ sudo apt update
[sudo] senha para sami: 
Atingido:1 http://deb.debian.org/debian  bookworm InRelease
Atingido:2 http://security.debian.org/debian-security  bookworm-security InRelease                                 
Atingido:3 http://repo.mysql.com/apt/debian  bookworm InRelease                                                    
Atingido:4 http://deb.debian.org/debian  bookworm-updates InRelease                                                
Atingido:5 https://packages.microsoft.com/debian/12/prod  bookworm InRelease
Atingido:6 https://packages.microsoft.com/repos/code  stable InRelease
Lendo listas de pacotes... Pronto
Construindo árvore de dependências... Pronto
Lendo informação de estado... Pronto        
All packages are up to date.
sami@sami-debian:~$ # I entered correctly pwd

I use KDE Plasma I was hoping that if I entered the terminal, I would be able to execute the commands as if I were a superuser, but it doesn't allow it. Without this, I have to log in as root all the time to do any minimal operation, like changing branches on github. I wanted to make the job easier. I just did a git clone and when I tried to change branches, it said that I didn't have permission to change something like index.lock. So should I, every time I work in the terminal, use sudo first? I didn't test using sudo git checkout branch. I should it?

## Overview I'm attempting to execute commands as a different user **without using quotation marks** as well as making sure the executed command **isn't inheriting environment** from the parent shell. [runuser](https://man.archlinux.org/man/runuser.1.en) looks like the perfect candidate for this job as it's going to be executed by a privileged user *(in a unattended script)*, there's no setuid bit, has login/PAM session support and it's a part of widely used util-linux package. ## Problem Edit: to clarify further: > The culprit here is that I'd like to switch between multiple users _within_ the same script and execute the commands _as they are written_ from the perspective of the user executing them. Currently variables like $USER or even ~/ gets expanded to the values from parent shell which breaks the entire setup. For a long time I've been using Bash's -c but this requires quotation marks which makes commands with e.g. regex difficult to read. Original question: > The goal is to display directory listening of user's home (meaning ~/ should translate to /home/build) as the build user _(where's a "polluted" shell would return /root)_. Quotation marks should not be used _(to avoid having to escape those with more advanced commands)_. The following approach almost works but it unfortunately inherits environment from parent's session:

$ whoami
root

$ runuser --user build -- ls -a ~/
ls: cannot open directory '/root/': Permission denied

Another alternative which I've tried is to create a login session but due to the nature of Bash, the arguments aren't parsed as [command_string](https://man.archlinux.org/man/bash.1.en#c) but instead as a script:

$ runuser --login build -- ls -a ~/
/usr/bin/ls: /usr/bin/ls: cannot execute binary file

Logically this is usually solved by supplying the -c argument to Bash but this bring us back to square one, it requires quotation marks:

$ runuser --login build -- -c 'set -x; ls -a ~/'
+ ls -a /home/build/

Invoking a _separate_ script fulfills all the requirements but I found this approach to be cumbersome to work with:

# run.sh
whoami
ls -a ~/

$ chown build run.sh
$ chmod +x run.sh
$ runuser build ./test.sh 
+ whoami
build
+ ls -a /home/build/

## Question Are there any other approaches which allows you to avoid quotation marks when executing commands as a different user in a clean environment? --- #### Update 1 Heredoc is the closest solution which fits all criteria but I'm happy to hear if there's more!

# run.sh
runuser --user build -- bash << EOF
set -x
ls -d ~/
whoami
EOF

# Result
+ ls -d /home/build/
/home/build/
+ whoami
build

#### Update 2 Exporting functions to subshells is also viable and preserves syntax highligh

function CMD {
  set -x
  echo $USER
  ls -d ~/
}
runuser --login build -- -c "$(declare -f CMD); CMD"

At boot im running following command: su vis -c 'QT_QPA_PLATFORM=offscreen /usr/bin/browser --version' /usr/bin/browser being a custom browser, which cannot be run as root. The script that is executing this command however is run as root, meaning to prevent /usr/bin/browser from being run as root I have to use su to switch to another user. This is a debian embedded system and because of the su this command is taking a long time(2+ min). I have seen that as a workaround you can disable session optional pam_systemd.so inside /etc/pam.d/common-session. Workaround mentioned here: https://serverfault.com/questions/1050717/why-su-command-takes-to-long-in-nested-debian-lxd-containers So i figured i can just disable it execute the command and then enable it again, like so:

sudo sed -i '/^session\s\+optional\s\+pam_systemd\.so/s/^/# /' /etc/pam.d/common-session

su vis -c 'QT_QPA_PLATFORM=offscreen /usr/bin/browser --version'

sudo sed -i '/^#\s\+session\s\+optional\s\+pam_systemd\.so/s/^#\s\+//' /etc/pam.d/common-session

the first sed adds a # to session optional pam_systemd.so and the second sed removes it again. This does indeed work, no more 2+ min waiting on each boot, but im just wondering if this causes any potential issues that im unaware of. The system is debian bullseye on armhf.

I basically need to do this: DUMMY=dummy sudo su - ec2-user -c 'echo $DUMMY' This doesn't work. How can I pass the env variable $DUMMY to su? -p doesn't work with -l.

I installed Kali Linux on a VM machine and I cannot change my user to root from the terminal using su. The command sudo works fine but when I try to su, it says "cannot execute bin/bash/****(my user name) not a directory".