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?
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. That's it. Usually every user should have access to temporary storage. Why you have limited such access , 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. Reports there are more full/complete.
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 email@example.com ● firstname.lastname@example.org - 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: /email@example.com └─15697 /var/www/live/.dropbox-dist/dropbox-lnx.x86_64-93.4.273/dropbox Apr 20 01:48:16 web2.example.com dropbox: 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: 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: 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: 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: 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: 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: 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: Done! Apr 20 01:48:19 web2.example.com systemd: Started Dropbox as a system service user live. Apr 20 01:48:22 web2.example.com sudo: 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 firstname.lastname@example.org 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
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.
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.
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.
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.
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.
The way we work is changing. Share and discover new ways to work smarter with Dropbox in our community.Sound good? Let's get started.
For more info on available support options, see this article.
If you found the answer to your question, please 'like' the post to say thanks to the user!