search

MichaIng / DietPi

Lightweight justice for your single-board computer!
https://dietpi.com/
GNU General Public License v2.0
4.84k stars 495 forks source link

Non-Root Desktop Autologin doesn't work #4007

Closed C0D3-M4513R closed 3 years ago

C0D3-M4513R commented 3 years ago

Creating a bug report/issue

When you switch from a desktop environment, such as lxde, mate, xfce or lxqt, to another by uninstalling the first and then installing the other, startx doesn't work as expected anymore

Required Information

Additional Information (if applicable)

Steps to reproduce

  1. Have a running dietpi install
  2. Install LXDE fully
  3. Reboot if asked
  4. Ideally make sure, that the LXDE works, when running startx
  5. Uninstall LXDE
  6. Install XFCE
  7. Reboot if asked
  8. Ideally make sure, that the XFCE works, when running startx
  9. Observe startxfailing

Expected behaviour

Actual behaviour

Extra details

Notice: I had a physical display , but also "TigerVNC Server" intalled, and both were starting a desptop environment, that would complain, if it was active more than one time? I eventually uninstalled, and found, that the initial problem still persisted. I do not think, that the VNC Server interfered here, because I uninstalled, then rebooted, and found the same auto behavior (I wasn't doing anything to the Pi remotely, such as accessing ssh or vnc, until I saw, that it tried to start the desktop-environment) as the boot before.

I dunno, if it is, that I switched desktop environments, or that I selected the user dietpi as the autologin user.

The Fix: I got everything working, after diagnosing the issue using these steps: I dunno, if these steps were nessesary, but they helped getting startx working, when executing as root (still doesn't work as non-root. I'll debug further):

  1. Find, that the package of the startx command is xinit
  2. sudo apt purge xinit xauth
  3. sudo apt install xinit xauth

I do NOT know, if I actually had to uninstall xauth here, but it was unsinstalled with a autopurge, so I let apt do it's thing, and just reinstalled it again.

C0D3-M4513R commented 3 years ago

On further investigation it seems, as if it is Not intended to autologin to a desktop enviorment as a non-root user? The command startxfce4 is giving me one permission error after the other. If I solve something, that is easy to do (such as not having perms to access /dev/ttyX) others just pop up. If I do startx, the error is xf86OpenConsole: Switching VT failed, or xf86OpenConsole: Cannot open virtual console 2 (Permission denied), depending, if I do not use ssh or if I do.

MichaIng commented 3 years ago

Many thanks for your report.

I would have expected that the startx command default client gets adjusted when uninstalling one desktop and installing a new one. We could check that on a desktop install and in case adjust it manually, but it would require some more checks, e.g. other installed X applications which may reasonably be default display managers, like other desktops of course but also LightDM login mask. I had the impression that this was handled satisfying in most situations, but I'll try to replicate the case and see if/what we can do to enhance it. EDIT: Ah in case of a VPN server, we hard-code the desktop session that was found installed for root user. So installing a new desktop indeed requires to either reinstall the VPN server or adjust the target desktop manually: /root/.vnc/xstartup Actually it makes sense to fallback to the default desktop manager here as well, so that LightDM mask shows up, when installed, as well on VNC connection to allow non-root user sessions 🤔.

On further investigation it seems, as if it is Not intended to autologin to a desktop enviorment as a non-root user?

It was planned but not yet implemented to automatically assign the chosen autologin user the required permissions for the desktop environment. E.g. usermod -aG video <username> to grant it access to the X server. usermod -aG tty <username> should only be required if you want to start a desktop session from a different console, e.g. run startx command on SSH to start a desktop on /dev/tty1, i.e. attached monitor. But it makes sense to have this restricted by default as long as the same user is not clearly logged in at /dev/tty1 already.

C0D3-M4513R commented 3 years ago

usermod -aG tty <username> helped, when sending a command from ssh to the tty on my pi's monitor. usermod -aG video <username> didn't do anything. I checked again, after removing video from . Btw, as I'm just using dietpi.

C0D3-M4513R commented 3 years ago

I would have expected that the startx command default client gets adjusted when uninstalling one desktop and installing a new one.

I dunno if that's the case, but I do belive so. Please try it. I am unsure, if I actually started the desktop-environment as non-root or as root.

MichaIng commented 3 years ago

With user dietpi in video group there were still permissions issues when starting Xfce? There is as well the render group for DRM access, but that should not be required for an X server session (desktop).

C0D3-M4513R commented 3 years ago

Just referencing a couple things here: Apperantly this bug is well known... https://gist.github.com/alepez/6273dc5220c1c5ec5f3f126e739d58bf https://github.com/mviereck/x11docker/issues/5 https://bbs.archlinux.org/viewtopic.php?id=192329 https://bugs.launchpad.net/ubuntu/+source/xinit/+bug/1562219 https://superuser.com/questions/845069/permissions-messed-up-on-x-server https://unix.stackexchange.com/questions/346383/run-second-x-server-from-within-x-as-a-systemd-service https://ubuntu-bugs.narkive.com/ZsgjjZIg/bug-1562219-new-xinit-will-not-work-as-non-root#post33

C0D3-M4513R commented 3 years ago

a chmod 660 /dev/tty* helped things further... (this should be temporary, since /dev is created newly on every boot, right?) The error went from xf86OpenConsole: Cannot open virtual console 3 (Permission denied) to xf86OpenConsole: Switching VT failed (ignore the different tty numbers everywhere) EDIT: I think, that I may have a working solution. I do not know, why, but It appears, that now /dev/tty1 is actually owned by dietpi, which means, that the automatic startx can take control of that tty without issues.

C0D3-M4513R commented 3 years ago

I think the important thing is to get tty1 be spawned as the user dietpi, so the tty will be owned by dietpi? EDIT: I dug around in my system, and it seems, that I have a file at /etc/systemd/system/getty@tty1.service.d/dietpi-autologin.conf. It further defines the tty1, and makes it spawn as dietpi? Contents of that file:

[Service]
ExecStart=
ExecStart=-/sbin/agetty -a dietpi --noclear %I $TERM

There is also /etc/systemd/system/getty@tty1.service.d/noclear.conf in that directory with the contents:

[Service]
TTYVTDisallocate=no

EDIT2: That shouldn't matter, since those files are autocreated by https://github.com/MichaIng/DietPi/blob/b354689141bf3b238b87d9ff83f33df5cf52173f/dietpi/dietpi-autostart#L178 EDIT3: After booting once with those files moved somewhere else, moving them back, and rebooting it is broken again?

C0D3-M4513R commented 3 years ago

Just as a reminder: I currently have dietpi only in the groups dietpi and video! After executing 

systemd-run \
--property PAMName=login \
--property StandardInput=tty \
--property TTYPath=/dev/tty1 \
 sh -c 'chvt 1 && startx'

(from https://unix.stackexchange.com/questions/346383/run-second-x-server-from-within-x-as-a-systemd-service) and killing the login-shell, the server starts as expected. Maybe add that as a service? This should only be temporary, but I do not know, how to reverse it. For now I just hope, that keeping the pi plugged out of everything will reset that change. (systemctl daemon-reload doesn't fix it, as well as a reboot, or forcing systemctl to update it's caches, by moving service files.) While that change is active, the desktop autostart works as expected. I assume, that this would also be unnessesary: https://github.com/MichaIng/DietPi/blob/b354689141bf3b238b87d9ff83f33df5cf52173f/dietpi/dietpi-login#L46

MichaIng commented 3 years ago

First of all, the TTY permissions are exactly as they should be, do not change those, that should never be required by any process that is intended to be executed by non-root users. The tty group is only intended to write to other TTYs, but not to directly read from them.

/dev/tty* devices are owned by the respective login user, once a login has been done, hence the dietpi owner once you logged in on that TTY via local console login or autologin. dietpi-autologin.conf leads to autologin with the user you chose via dietpi-autostart, the result is the same as if you would login manually with that user. /dev/tty1 owner is then changed, but not due to the config file itself, but due to the fact that user dietpi logged in on that TTY. It is handed back to root user, once you log out.

noclear.conf has no influence in this regards, it only leads to boot messages being not removed when the login prompt appears. But after login, everything is cleared anyway. That is a non-default file placed on Raspbian images (pi-gen) only: https://github.com/RPi-Distro/pi-gen/blob/master/stage1/01-sys-tweaks/files/noclear.conf

This should only be temporary, but I do not know, how to reverse it.

Logging out the desktop session stops that temporary systemd service. You only started startx as temporary service with PAMName=login (aside of everything else that is standard), so no permanent changes. You mean starting the desktop now still works after reboot? It cannot really be due to executing this command, actually. Still, good to know about PAMName=login, not exactly sure what role it plays here, will have to play around to find the essence and how to implement best for non-root desktop sessions.

Joulinar commented 3 years ago

linking an older issue with possible workaround that was still on the list to be tested https://github.com/MichaIng/DietPi/issues/3586

C0D3-M4513R commented 3 years ago

First of all, the TTY permissions are exactly as they should be, do not change those, that should never be required by any process that is intended to be executed by non-root users.

That was for temporary testing. Those changes are not required, just like you said.

/dev/tty1 owner is then changed, but not due to the config file itself, but due to the fact that user dietpi logged in on that TTY.

That somehow didn't happen.

You mean starting the desktop now still works after reboot?

Yes. That is correct. After executing the command in my previous post, it works, even after a reboot. I shouldn't mark this as closed, but I can't test any further.

C0D3-M4513R commented 3 years ago

Still, good to know about PAMName=login, not exactly sure what role it plays here, will have to play around to find the essence and how to implement best for non-root desktop sessions.

I can help with that: from https://unix.stackexchange.com/a/473041/448036

The magic is in defining PAMName=, to open a PAM session, and associating that session with the specific TTY. This gets pam_systemd to do what you want. I spoofed login - though technically you're supposed to define a new PAM "service name" in case it needs some special treatment.

MichaIng commented 3 years ago

Yeah, a desktop session however automatically invoke PAM, AFAIK.

C0D3-M4513R commented 3 years ago

Yeah, a desktop session however automatically invoke PAM, AFAIK.

Maybe so, but apparently running startx from dietpi has the consequense, that on start it cannot configure everything correctly, because it is not root. Therefore the desktop doesn't boot? If you run 

systemd-run \
--property PAMName=login \
--property StandardInput=tty \
--property User=dietpi \
--property TTYPath=/dev/tty1 \
 sh -c 'chvt 1 && startx'

as root, it sets all permissions correctly for startx (?), but the startx, from dietpi-login in run (observed).

ravenclaw900 commented 3 years ago

I tried running that, and it didn't work for me. However, chmod ug+s /usr/lib/xorg/Xorg did.

MichaIng commented 3 years ago

Note that chmod ug+s /usr/lib/xorg/Xorg means that every user who calls Xorg will gain full root permissions through it, breaking basically the whole security concept :wink:.

If there is no reliable way to allow non-root users start a fully functional desktop session via system group memberships, the only viable solution I see is to use LightDM with autologin, which is pretty easy: https://www.maketecheasier.com/enable-autologin-lightdm/ The X server session then runs as lightdm user (we could review the way that user is able to do it) and the client desktop session as login user of course.

C0D3-M4513R commented 3 years ago

I tried running that, and it didn't work for me.

How about we remove (non-root) Desktop Autologin for now, add it back later, if there is a better way found in this issue and flag this issue as an improvement/enhancement?

MichaIng commented 3 years ago

Probably a warning would do. The method to choose the user for auto-logins is implemented in a generic way currently and in other cases as well permissions might be required. So to keep some freedom for admins who manage to deal with the permissions, I think it would be sufficient to warn about it and recommend to switch back to root or LightDM login in case issues are faced. LightDM autologin actually looks so easy and reasonable that I'll find time to implement it with next release.

MichaIng commented 3 years ago

Marking this as closed in favour of #3586.