Highlighted
Posted by
Photon

Security/ Bad Packaging: Teamviewer updates re-enable disabled teamviewerd.service

I have disabled teamviewerd.service for security reasons with "sudo systemctl disable teamviwerd.service". I only start the service when I actually need to use Teamviewer.

I notice that every Teamviewer update overwrites the systemd configuration and re-enables the background service without my consent. I am not happy with the behaviour of Teamviewer updates und would highly recommend to modify the installation script in a way that the user is asked if the startup configuration should be changed or not. This is common practice in the Linux world.

My system: Ubuntu 18.04 64bit.

4 Replies
Posted by
Photon

Re: Security/ Bad Packaging: Teamviewer updates re-enable disabled teamviewerd.service

I've been running into this problem for a while, too, and was hoping that the company Teamviewer would eventually fix this on their own.  That didn't happen.

This is incredibly annoying as I have to manually disable and stop teamviewer on every update. If your daemon is disabled, it should *stay* disabled.

Please remove that "feature", thanks.

Highlighted
Posted by
Henagon

Re: Security/ Bad Packaging: Teamviewer updates re-enable disabled teamviewerd.service

I agree with this, especially since it is pulling logs from other services on the system. For now I am running the following cronjob.

@reboot /usr/bin/bash -c '[ `systemctl is-enabled teamviewerd` != 'disabled' ] && systemctl disable --now teamviewerd'
Highlighted
Posted by
Photon

Re: Security/ Bad Packaging: Teamviewer updates re-enable disabled teamviewerd.service

There are sure solutions like cron script but I am convinced, that sw is very much about trust and the question is, how can I trust sw incl. its producer, who enable access to my computer despite I refused it.

1. Such an importatnt item should be manageble and visible even by very stupid user because of even he/she has the right to make the decision when exactly to open and when to close this door. So even workable commandline solution is bad.

2. I had a problem with teamviewer even before, because of I didn't see a clear description, who has the control of the permission list? Is that done e.g. by some keystore on my computer (where:?) or is that somewhere at Teamviewer server? I.e. is that technically possible, that Teamviewer company "changes my decision" simillarly to the one of not starting the service?

The second item was a blocker for me for professional use, the mentioned re-enabling of running in background means sorry for my mum, who likes it.

From my point of view is the only solution uninstall and check some possible residuals.

 

Highlighted
Posted by
Photon

Re: Security/ Bad Packaging: Teamviewer updates re-enable disabled teamviewerd.service

This is something that also annoys me for a long time.
Recently I tweeted to @teamviewer_help and they were, at least, responsive.

As I said in one of my tweets I would be glad to help fixing this.
I had a look at the RPM postinstall script to understand what changes would be required.The following changes should do it for systemD but a little bit more effort is required to support other tecnologies.

*** postinstall.sh.orig 2020-05-28 10:59:00.**Please do not post TeamViewer IDs** +0100
--- postinstall.sh      2020-05-28 10:58:36.**Please do not post TeamViewer IDs** +0100
***************
*** 25,35 ****
  {
    local installCount="$1"
    local action=$(RPMAction)
  
!   [ "$action" = 'upgrade' ] && removeDaemon  # during upgrade: remove daemon, then reinstall
  
    Configure
    UpdateIconCache
  }
  
  function Configure()
--- 25,48 ----
  {
    local installCount="$1"
    local action=$(RPMAction)
+   local daemonStatusBeforeUpgrade
  
!   if [ "$action" = 'upgrade' ]; then
!     # save daemon status so that it can be restored after the upgrade
!     daemonStatusBeforeUpgrade=$( cmdDaemon 'status' )
! 
!     removeDaemon  # during upgrade: remove daemon, then reinstall
!   fi
  
    Configure
    UpdateIconCache
+ 
+   # restore service status before the upgrade
+   case "$daemonStatusBeforeUpgrade" in
+     disabled)
+       cmdDaemon 'disable'
+       ;;
+   esac
  }
  
  function Configure()


If there's a plan to implement such a fix, I am available to provide additional help.

Cheers,
Paulo A. Silva