cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Announcements
Learn all about apps and Dropbox integrations to make working from home easy here!

Dropbox installs & integrations

Connect your tools and content together with help from the Dropbox Community. Join a discussion or post a question of your own to get started.

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Dropbox on Linux attempting to execute as root via sudo - any ideas?

Dropbox on Linux attempting to execute as root via sudo - any ideas?

boxdropping
Explorer | Level 4

Excuse me if install/integration isn't the correct area to post this - nothing else matches the category.

I run dropbox for Linux (x86_64), version 86.4.146, as a separate user 'dropboxuser'. I have noticed as of late by way of security e-mails from sudo that the dropboxuser is attempting to execute scripts in /tmp. See the example mails below.

 

mybox : Dec 6 12:21:52 : dropboxuser : user NOT in sudoers ; TTY=pts/7 ; PWD=/ ; USER=root ; COMMAND=/bin/sh /tmp/tmpkq6j6p3e

mybox : Dec 3 22:56:08 : dropboxuser : user NOT in sudoers ; TTY=pts/7 ; PWD=/opt/dropbox ; USER=root ; COMMAND=/bin/sh /tmp/tmp4ey9y9kd

mybox : Dec 3 22:56:07 : dropboxuser : user NOT in sudoers ; TTY=pts/7 ; PWD=/opt/dropbox ; USER=root ; COMMAND=/bin/sh /tmp/tmpiizxl2c7

mybox : Nov 14 19:09:17 : dropboxuser : user NOT in sudoers ; TTY=pts/7 ; PWD=/ ; USER=root ; COMMAND=/bin/sh /tmp/tmpuii0fwie

 

There doesn't seem to be any rhyme or reason to the time of day these execute, but it is always attempting to execute some script in /tmp. These files no longer exist and I have no idea what the contents were.

Does anyone know why dropboxd would be attempting to gain root privileges and what is the contents of these files?

Thanks

 

8 Replies 8

Re: dropboxd on Linux attempting to execute as root via sudo - any ideas?

Здравко
Super Collaborator | Level 20

Hi @boxdropping,

No, you are wrong. Dropbox application never tries gain root access, actually. Seems your sandboxing tool assumes so, for some reason. From time to time the application checks for updates and default temporary directory is used for. :wink: That's it. Usually every user should have access to temporary storage. Why you have limited such access :thinking:, only you can give this answer to yourself or read carefully documentation for other possible tools used, able affect.

Hope this adds some clarity.

PS: I wasn't able see any secure confirmation that Dropbox application is trying gain root access. You assume so by username base, only! Other application/tool also could run in same context. Be careful. Check which one is the actual application trying this access. If you want careful limit Dropbox application (or any other), use AppArmor. :wink: Reports there are more full/complete.

Dropbox user on Linux attempting to sudo to root

counterpoint
Helpful | Level 5

This was raised previously in another post, but was dismissed rather hastily. I am experiencing much the same.

 

Dropbox is installed on Debian 9 and is run as the user "live" whose home directory is /var/www/live. I do not want live to be able to sudo to root in general. Occasionally, as in the earlier post, I have received security notifications from the server saying that user live has been refused permission to sudo to root. This only happens once in several weeks.

 

There is no restriction on the /tmp directory:

drwxrwxrwt   8 root root 45056 Apr 20 01:55 tmp

Dropbox has been running as a result of crontab starting it at boot time. Now I have created a systemd service to run Dropbox. Starting the service generates messages about failed sudo to root. And this is shown in the status of the service:

root@web2:/etc/systemd/system# systemctl status dropbox@live.service
● dropbox@live.service - Dropbox as a system service user live
   Loaded: loaded (/etc/systemd/system/dropbox@.service; enabled; vendor preset: enabled)
   Active: active (running) since Mon 2020-04-20 01:48:19 PDT; 16min ago
  Process: 13914 ExecStop=/usr/bin/dropbox stop (code=exited, status=0/SUCCESS)
  Process: 15696 ExecStart=/usr/bin/dropbox start (code=exited, status=0/SUCCESS)
 Main PID: 15697 (dropbox)
    Tasks: 88 (limit: 4915)
   CGroup: /system.slice/system-dropbox.slice/dropbox@live.service
           └─15697 /var/www/live/.dropbox-dist/dropbox-lnx.x86_64-93.4.273/dropbox

Apr 20 01:48:16 web2.example.com dropbox[15696]: dropbox: load fq extension '/var/www/live/.dropbox-dist/dropbox-lnx.x86_64-93.4.273/cryptography.hazmat.bindings._const
Apr 20 01:48:16 web2.example.com dropbox[15696]: dropbox: load fq extension '/var/www/live/.dropbox-dist/dropbox-lnx.x86_64-93.4.273/cryptography.hazmat.bindings._opens
Apr 20 01:48:16 web2.example.com dropbox[15696]: dropbox: load fq extension '/var/www/live/.dropbox-dist/dropbox-lnx.x86_64-93.4.273/cryptography.hazmat.bindings._paddi
Apr 20 01:48:16 web2.example.com dropbox[15696]: dropbox: load fq extension '/var/www/live/.dropbox-dist/dropbox-lnx.x86_64-93.4.273/psutil._psutil_linux.cpython-37m-x8
Apr 20 01:48:16 web2.example.com dropbox[15696]: dropbox: load fq extension '/var/www/live/.dropbox-dist/dropbox-lnx.x86_64-93.4.273/psutil._psutil_posix.cpython-37m-x8
Apr 20 01:48:17 web2.example.com dropbox[15696]: dropbox: load fq extension '/var/www/live/.dropbox-dist/dropbox-lnx.x86_64-93.4.273/apex._apex.cpython-37m-x86_64-linux
Apr 20 01:48:17 web2.example.com dropbox[15696]: dropbox: load fq extension '/var/www/live/.dropbox-dist/dropbox-lnx.x86_64-93.4.273/tornado.speedups.cpython-37m-x86_64
Apr 20 01:48:19 web2.example.com dropbox[15696]: Done!
Apr 20 01:48:19 web2.example.com systemd[1]: Started Dropbox as a system service user live.
Apr 20 01:48:22 web2.example.com sudo[16107]: pam_unix(sudo:auth): conversation failed

There is a consistently repeatable issue that if the service is restarted, shortly afterwards, an error appears concerning sudo to root:

root@web2:/etc/systemd/system# systemctl restart dropbox@live.service
root@web2:/etc/systemd/system# 2020 Apr 20 02:05:48 web2 pam_unix(sudo:auth): auth could not identify password for [live]
2020 Apr 20 02:05:48 web2     live : user NOT in sudoers ; TTY=unknown ; PWD=/var/www/live ; USER=root ; COMMAND=/bin/sh /tmp/tmpqw34msg6

The service is defined as:

[Unit]
Description=Dropbox as a system service user %i

[Service]
Type=forking
ExecStart=/usr/bin/dropbox start
ExecStop=/usr/bin/dropbox stop
User=%i
Group=%i
# 'LANG' might be unnecessary, since systemd already sets the
# locale for all services according to "/etc/locale.conf".
# Run `systemctl show-environment` to make sure.
Environment=LANG=en_US.utf-8

[Install]
WantedBy=multi-user.target

 

Re: Dropbox user on Linux attempting to sudo to root

Ntrcessor
New member | Level 2

Dropbox is doing this on my machine as well, however, on my machine when I sign in, it is attempting to run the scripts and pops up an auth dialog. The auth dialog doesn't identify as being with Dropbox. I was able to identify it with xprop as being a /bin/sh script.

Used ps aux to find any such process, there was only one being run from /tmp.

Catted the /tmp and it is 2 lines:

chown -h -R #### "/path to my dropbox"

chmod -R urwX "/path to my dorpbox"

where #### is my userid and "path to my dropbox" is the actual path to my dropbox. This seems to be a kludgy way to mark things

as being owned by the user, and overrides other settings the user may have placed on the files themselves. (i.e. may want to prevent a file from being overwritten so removes the w access.

I haven't been allowing this to run, and have not had any issues with Dropbox to date.

Re: Dropbox user on Linux attempting to sudo to root

counterpoint
Helpful | Level 5

Thanks for clarifying the issue, Ntrcessor. However, it seems very unsatisfactory. It isn't going to work if Dropbox is running as a user with no special privileges. And it is inclined to result in a warning email about the attempt to sudo, which does not make it clear that it is Dropbox that is the cause. At first, I thought it was a hack attempt, with someone running a script that attempted to sudo to root. The temporary file had always disappeared before I had time to look at it.

 

Since the mechanism is unreliable and likely to generate alarms, Dropbox ought to look for alternatives, if any are needed.

Re: dropboxd on Linux attempting to execute as root via sudo - any ideas?

richieHH
Explorer | Level 4

Not true. It does indeed sometimes prompt for admin privileges. Im yet to figure out exactly when 

Re: dropboxd on Linux attempting to execute as root via sudo - any ideas?

counterpoint
Helpful | Level 5

What's not true? As I understand it, this thread is about Dropbox on a headless Linux server. My first message here was a new thread, although it referred to this thread. Moderators combined them. My comments were certainly about headless servers. Dropbox can't prompt for anything on a headless server. I regularly receive emails like:

web2.example.com : Jun 18 19:43:26 2020 : live : user NOT in sudoers ; TTY=unknown ; PWD=/var/www/live ; USER=root ; COMMAND=/bin/sh /tmp/tmp1ri8et4_

These were tracked down to Dropbox. The script is a temporary file and is always gone by the time there is a chance to look. Ntrcessor kindly provided further details of what is going on.

Re: dropboxd on Linux attempting to execute as root via sudo - any ideas?

Ntrcessor
New member | Level 2

You could use the listed contents of the temp file to write your own cron job that runs once a day to accomplish the same thing. It won't stop the errors in the logfile, but it'll accomplish what dropbox is trying to do with a kludge.

 

something along the lines of:

chown -R $userid /home/$username/Dropbox/*

chmod -R -urwx /home/$username/Dropbox/*

 

So if you have multiple users, you could check for the existience of Dropbox in the profile, and then parse userid/username from the directory. This would probably be addressed if Dropbox would write a proper installer for *.deb and *.rpm type systems, and actually installed a proper cron-job for the user. But the user couldn't run the chown. If Dropbox is installed on a per user instance, chown shouldn't need to be run, and only the chmod should.

Re: dropboxd on Linux attempting to execute as root via sudo - any ideas?

counterpoint
Helpful | Level 5

Good points. Actually, I'm wondering about going off in a different direction altogether. Sorry for my ignorance, but I have only recently discovered rclone. It is available from standard repositories, is compatible with many cloud storage services including Dropbox. It installs as a single file, not dragging in a lot of other stuff.

 

It wouldn't suit everybody, as it doesn't do a two way sync, it only operates one way. Although you can run it in either direction, so it would be possible to run it once for each direction. It doesn't automatically maintain synchronisation either, it only does a one off sync. But for my purposes that would suffice. The aim is to update files on a server when users add or change them on their desktops, using Dropbox folders. The server doesn't make changes of its own. And running the sync every 5 minutes (using cron) would provide adequate responsiveness.

 

I've already got this running against my personal Nextcloud storage to sync music files to a headless DLNA server on my home network. Runs very well. Seems a very good way to deliver files to a server in a user friendly fashion.

Poll
How do you get refocussed while working from home? Do you find any of these options keep you from getting distracted?
Who's talking

Top contributors to this post

What do Dropbox user levels mean?
Need more support?