Dropbox attempts to run /bin/sh as superuser on startup

[Joshua R.19]

I'm trying to identify the cause of a rather puzzling issue with Dropbox, currently installed on Linux.

Whenever I start dropbox, I'm greeted with a modal within a few seconds which is attempting to run /bin/sh as superuser. I do not allow dropbox to do this, and tend to quit the modal. After having done so, having checked my journal, I see the following log entry:

Feb 04 01:25:59 minimus polkitd[844]: Operator of unix-session:2 FAILED to authenticate to gain authorization for action org.freedesktop.policykit.exec for unix-process:22361:815809 [/home/joshua/.dropbox-dist/dropbox-lnx.x86_64-90.3.298/dropbox /newerversion] (owned by unix-user:joshua)

And having checked the process ID 22361, it is indeed Dropbox which is trying to gain elevation and to execute a file in /tmp:

joshua   22361  6.5  1.5 7488604 514984 ?      Sl   01:24   0:43 /home/joshua/.dropbox-dist/dropbox-lnx.x86_64-90.3.298/dropbox /newerversion

Sadly Dropbox immediately deletes this file upon failing to execute it, so I'm not sure what it's doing.

If someone could let me know why Dropbox does this, and what it's attempting to do, and ideally how to stop this rather aberrant behaviour, that would be wonderful. Thanks!

[Lusil]

Hey there @Joshua R.19, thanks for checking in with us! I'd be more than happy to help look into this with you. 

As a first step, could it be that you have another third party app interacting with your Dropbox folder when you launch the desktop app, like a database? 

Let me know what you find!

[Joshua R.19]

I don't have any third party apps interacting with my Dropbox folder when I launch the app, no - but I do have third party apps accessing it later on, from IDEs, to running docker containers based on dockerfiles & compose files stored within the Dropbox folder.

[Lusil]

Thanks for clarifying that for me, @Joshua R.19. 

Could you try temporarily closing/disabling those apps before running the Dropbox desktop app and see if you get the same behavior?

Keep me posted!

[Joshua R.19]

Closing those apps seems to have no effect, Dropbox still attempts to run /bin/sh as superuser.

[Здравко]

Hi @Joshua R.19,

If I have to bet, your app tries autoupdate. Usually, updater is placed on a temporary place (not on the root folder, like in your case), but inside '/tmp/blabla-Dropbox-blabla/' (or something like). In all case the folder have to be accessible for write, read and execute (which '/tmp' normally is). Why your beta build tries access the system root (where write is usually prohibited, of course) I have no idea - probably a beta build bug. Is there some reason you don't use stable, but beta build?! Try stable build.

[Joshua R.19]

I don't believe it's the updater, I'm using a normal release rather than any alpha/beta. Unfortunately Dropbox deletes the file after failing to execute it, but I managed to get a copy of it by switching to a different tty and copying the file before cancelling the dialog. The file content was as follows:

#!/bin/bash
chown -h -R 1000 "/home/joshua/Dropbox"
chmod  -R u+rwX "/home/joshua/Dropbox"
echo Done%     

So it's trying to change the ownership of the Dropbox directory to me (UID 1000), and then recursively setting read/write/execute permissions on all subfiles/folders. Interestingly if I execute this on my machine manually, Dropbox will still attempt to execute it again on my machine (and the various other machines that I work on) on every startup. Please can we elevate this to someone who works on the Linux team at Dropbox to find out what's going on, and hopefully file a bug report? Dropbox should not be doing this on every startup, even if permissions aren't ideal - the app should notify me, rather than just barging in and trying to get root on my machine and executing a script in /tmp - this is not good behaviour by any stretch of the imagination.

Separately, the file being executed is simply `/tmp/tmp.<random string>`, as far as I know that kind of format is generally created by utilities such as `mktemp`

[Здравко]

I fully agree with you - Dropbox have to ask user, not decide behind.

One clarification: I'm a user like you and can't escalate anything. I'm still waiting a response for question placed half year ago, so don't rely too much.

---

@Joshua R.19 wrote:

..., I'm using a normal release rather than any alpha/beta. ...

---

Wow... If you take a look more carefully in your initial post:

... /home/joshua/.dropbox-dist/dropbox-lnx.x86_64-90.3.298/dropbox ...

Could be seen you use v.90.3.298 (same have to be shown in "Properties" application dialog, "General" tab). Second number '3' denote a beta build! For stable build this number has to be '4'! Available releases could be seen here. Probably your "Early releases" (in "General" tab of the "Personal account" settings) is turned on. Turn it off, quit your Dropbox application and execute:

rm -rf ~/.dropbox-dist
dropbox start -i

So, latest stable build will be automatically installed and... let's hope the issue will gone.

Hope this helps.

[mbebelveras]

Hi,

---

@Joshua R.19  escreveu:

So it's trying to change the ownership of the Dropbox directory to me (UID 1000), and then recursively setting read/write/execute permissions on all subfiles/folders. Interestingly if I execute this on my machine manually, Dropbox will still attempt to execute it again on my machine (and the various other machines that I work on) on every startup. Please can we elevate this to someone who works on the Linux team at Dropbox to find out what's going on, and hopefully file a bug report? Dropbox should not be doing this on every startup, even if permissions aren't ideal - the app should notify me, rather than just barging in and trying to get root on my machine and executing a script in /tmp - this is not good behaviour by any stretch of the imagination.

Separately, the file being executed is simply `/tmp/tmp.<random string>`, as far as I know that kind of format is generally created by utilities such as `mktemp`

---

It is not a good behavior at all !!!
My Dropbox version is v90.4.307, and I'm experiencing the same issue.

[Joshua R.19]

@Lusilcan we get a response from the development team on this please?