[remoting host] start-host should never use PolicyKit for root elevation |
|
Issue descriptionCRD needs root privileges during first-time setup (to add the user to chrome-remote-desktop group account). On Linux, it uses 'pkexec' if $DISPLAY is set, otherwise it uses 'sudo': https://cs.chromium.org/chromium/src/remoting/host/linux/linux_me2me_host.py?l=1475&rcl=0e5d469e5aaf3ed3b57a80b1b46ba3148f40db0b The start-host tool, however, will usually be executed from a remote SSH session. In that case, if $DISPLAY is set, it means that SSH is configured to forward a local X11 session. PolicyKit elevation will almost certainly fail in that situation. We should consider fixing start-host so it ignores $DISPLAY and always uses text-based prompting. It doesn't make sense to try to do graphical prompting on a different machine from the process that is being elevated to root. Note that this only applies to start-host. The local CRD setup via Chrome must strongly prefer graphical prompting (as the /dev/tty running Chrome is almost certainly not usable).
,
Feb 2 2018
The annoying thing is that, as far as I can tell, this *should* just work. One should always be able to use PolicyKit, and it should prompt using an agent if available, and otherwise fallback to prompting on the console. In practice, even when pkexec correctly falls back to prompting for a password on the console, it then fails after the password has been provided. I've noticed this on my home computer, too. I can run `systemctl restart` over SSH, and it will correctly prompt for my password on the console and remote. `pkexec`, however, will prompt for my password and fail, for no discernible reason, even though it works with a graphical agent.
,
Feb 2 2018
remote -> reboot
,
Feb 2 2018
It's a bit strange that PolicyKit would prompt for a password, and then say "no" after the fact? I think PK is seat-based, so if there's no agent or no seat or whatever, PK apparently decides that nothing should be allowed. The password prompt verifies who you are, but it doesn't say anything about what you're allowed to do, as far as PK is concerned. It's unfortunate that PK doesn't fall back to the standard Unix paradigm of "root can do anything". But it's maybe understandable from a security perspective - PK does not give special treatment to the "root" user.
,
Feb 2 2018
I think the default behavior of PK is described in the manpage for pklocalauthority. See also the output of sudo grep -r AdminIdentities /etc/polkit-1 There is a default config file from Debian that allows the "sudo" Unix group to perform admin operations. But this may be overridden by a file starting with a higher number.
,
Feb 9 2018
I've verified that the problem with pkexec over SSH did not occur on Goobuntu Trusty. Also, systemctl *does* work on Rodete, even though it also uses PolicyKit. On Goobuntu: $ pkexec id -u ==== AUTHENTICATING FOR org.freedesktop.policykit.exec === Authentication is needed to run `/usr/bin/id' as the super user Authenticating as: Erik Jensen (rkjnsn) Password: ==== AUTHENTICATION COMPLETE === 0 On Rodete: $ pkexec id -u ==== AUTHENTICATING FOR org.freedesktop.policykit.exec === Authentication is needed to run `/usr/bin/id' as the super user Authenticating as: Erik Jensen (rkjnsn) Password: polkit-agent-helper-1: error response to PolicyKit daemon: GDBus.Error:org.freedesktop.PolicyKit1.Error.Failed: No session for cookie ==== AUTHENTICATION FAILED === Error executing command as another user: Not authorized This incident has been reported. However, also on Rodete: $ systemctl restart chrome-remote-desktop.service ==== AUTHENTICATING FOR org.freedesktop.systemd1.manage-units === Authentication is required to restart 'chrome-remote-desktop.service'. Authenticating as: Erik Jensen (rkjnsn) Password: ==== AUTHENTICATION COMPLETE === (CRD is successfully restarted) |
|
►
Sign in to add a comment |
|
Comment 1 by jamiewa...@chromium.org
, Jan 23 2018Status: Assigned (was: Untriaged)