FS#58159 - [systemd]tty permissions changed to root after killing Xserver
Attached to Project:
Arch Linux
Opened by stef204 (stef204) - Saturday, 07 April 2018, 21:00 GMT
Last edited by Buggy McBugFace (bugbot) - Saturday, 25 November 2023, 20:13 GMT
Opened by stef204 (stef204) - Saturday, 07 April 2018, 21:00 GMT
Last edited by Buggy McBugFace (bugbot) - Saturday, 25 November 2023, 20:13 GMT
|
Details
Description:
When dropping down to Linux Console after killing X server; the ownership of /dev/ttyX (whichever tty was used to "startx") is set to root:root as opposed to keeping it as $USER:tty (as it is when first logging in to system). This creates permission problems: for example, after killing X and dropping back down to Linux Console, I can no longer edit files with emacsclient, as this change of ownership creates a permission error (cannot open display). I start emacs server with a USER systemd unit on login. And before startx, when /dev/ttyX is owned by $USER:tty, emacsclient works as expected. I have checked this ownership change on other distros and have not found this problem present in any, IOW, when killing X on Debian (and other tested distros), the ownership of /dev/ttX remains $USER:tty. I have added myself to group "tty" but no change. Additional info: * package version(s) coreutils 8.29-1 linux-zen 4.15.15-1 xorg-server 1.19.6+13+gd0d1a694f-1 i3-wm 4.15-1 * config and/or log files etc. % uname -a Linux archlinux 4.15.15-1-zen #1 ZEN SMP PREEMPT Sat Mar 31 23:59:18 UTC 2018 x86_64 GNU/Linux (This problem is present with linux and linux-lts as well.) % cat /proc/cmdline BOOT_IMAGE=/boot/vmlinuz-linux-zen root=UUID=xxxxxxxxxxx rw acpi_backlight=video fbcon=scrollback:256k % cat /etc/X11/Xwrapper.config needs_root_rights=no (I've tried to comment this line out, reboot but no change) Steps to reproduce: 1) Boot into linux, linux-zen or linux-lts and login. You can check ownership and perms at this point: % ls -l /dev/tty1 crw------- 1 $USER:tty 4, 2 Apr 7 22:36 /dev/tty1 and the octal perm: crw------- 600 /dev/tty1 This is correct and expected. 2) % startx Let X server and window manager start. Exit X "gracefully" by using window manager's own method (or just kill X) 3) check ownership/permissions: % ls -l /dev/tty1 crw------- 1 root:root 4, 2 Apr 7 25:36 /dev/tty1 and the octal perm: crw------- 600 /dev/tty1 4) try to open emacsclient: error, cannot open display, no permission 5) sudo chown $USER:tty /dev/tty1 5a) check ownership to make sure % ls -l /dev/tty1 crw------- 1 $USER:tty 4, 2 Apr 7 25:36 /dev/tty1 and the octal perm: crw------- 600 /dev/tty1 6) % emacsclient somefile This now works properly and opens the file, etc. Again, I have checked this against 3 or 4 other distros, and none change ownership of/dev/ttyX, all return to same $USER:tty once X is killed. It is difficult to identify where the problems lies, which package creates this ~edge case. It could be something local to my install but cannot figure out what, This problem has been present for a at least 2 years if not longer and my system is pretty much always up to date. I have tried with DWM as windows manager and the error and behavior is the same so I would tend to think not WM related. (Note I have replaced ny actual user name with $USER in this bug report.) |
This task depends upon
Closed by Buggy McBugFace (bugbot)
Saturday, 25 November 2023, 20:13 GMT
Reason for closing: Moved
Additional comments about closing: https://gitlab.archlinux.org/archlinux/p ackaging/packages/systemd/issues/2
Saturday, 25 November 2023, 20:13 GMT
Reason for closing: Moved
Additional comments about closing: https://gitlab.archlinux.org/archlinux/p ackaging/packages/systemd/issues/2
Basically, during startx or after; the owner of /dev/ttyX from which X was started changes from "$USER:tty" to "root:tty" (probably by xorg-server or some related script or package) and stays that way, even once "X" is exited gracefully or not.
Additional info: a check using 'ps aux | grep xorg' reveals that "/usr/lib/xorg-server/Xorg" IS owned by $USER during X session.
This also seems to happen on debian as someone has opened a github issue with systemd https://github.com/systemd/systemd/issues/10103.