Am Di., 26. Jan. 2021 um 08:57 Uhr schrieb Petr Lautrbach <plautrba@xxxxxxxxxx>: > > Nicolas Iooss <nicolas.iooss@xxxxxxx> writes: > > > > > Hello, > > I am quite uncomfortable with this approach of keeping only one more > > variable: why is only XDG_RUNTIME_DIR added, and not also > > XDG_DATA_DIRS, XDG_SESSION_ID, XDG_SESSION_PATH, etc.? For example > > someone pointed out in > > https://github.com/systemd/systemd/issues/18301#issuecomment-763933678 > > that DBUS_SESSION_BUS_ADDRESS could also need to be preserved, so > > there seem to be a long list of items. > > > > Moreover I am wondering whether this would be fine to keep such > > environment variables while newrole uses the information from another > > user (i.e. when newrole is built with USE_AUDIT and > > audit_getloginuid() != getuid() because the user changed their UID ; > > in such a situation newrole resets $HOME and $SHELL to the HOME of > > audit_getloginuid()). > > > > In my humble opinion, I also do not understand why TERM, DISPLAY and > > XAUTHORITY are kept but not LANG, LC_ALL, and all other LC_... > > variables. I understand that there exist dangerous environment > > variables (LD_LIBRARY_PATH, LD_PRELOAD, ...), that resetting the > > environment to a minimal one is nice, and that using "newrole > > --preserve-environment" could seem dangerous. For information, sudo > > has been maintaining a list of "bad" variables, of variables with > > potential dangerous values and of variables preserved by default, in > > https://github.com/sudo-project/sudo/blob/SUDO_1_9_5p1/plugins/sudoers/env.c#L134-L228. > > > > This being said, I have never really used newrole but to expose a bug > > in "sudo -r" a few years ago > > (https://bugzilla.sudo.ws/show_bug.cgi?id=611 "root user can change > > its SELinux context without password"). Since then I have always used > > sudo to change role, with the advantage that it can be configured to > > keep some environment variables, so I am not really the best reviewer > > for such a patch (and also I am a little bit confused about the > > "isolation guarantees" that newrole implements, and I am not sure > > whether keeping XDG_RUNTIME_DIR would not break such guarantees). > > > > TL;DR: can another maintainer more familiar with newrole review this > > patch, please? > > > > Thanks, > > Nicolas > > I think it does not make much sense to keep XDG_RUNTIME_DIR > > When you change a role, type or level, it's like changing a > linux user and it should be completely new session. > > In Fedora, sysadm_t is not even allow to get status of > staff_t units: > > [staff@rawhide ~]$ echo $XDG_RUNTIME_DIR > /run/user/1001 > [staff@rawhide ~]$ newrole -r sysadm_r > Password: > [staff@rawhide ~]$ export XDG_RUNTIME_DIR=/run/user/1001 > [staff@rawhide ~]$ systemctl --user list-units > Failed to list units: Access denied > > systemd[33326]: selinux: avc: denied { status } for auid=n/a uid=1001 gid=1001 cmdline="" scontext=staff_u:sysadm_r:sysadm_t:s0-s0:c0.c1023 tcontext=staff_u:staff_r:staff_t:s0-s0:c0.c1023 tclass=system permissive=0 > systemd[33326]: selinux: avc: denied { status } for auid=n/a uid=1001 gid=1001 cmdline="" scontext=staff_u:sysadm_r:sysadm_t:s0-s0:c0.c1023 tcontext=staff_u:staff_r:staff_t:s0-s0:c0.c1023 tclass=system permissive=0 > > There's also question why one would use newrole to control their a > systemd user session when it's possible to control it directly. > Thanks for your comments. Seems this uncommon use case is not worth the trouble at all, and one can as fallback set environment variables via the user's shell settings (~/.bashrc). Please disregard this patch.
