Fixing Dropbox Admin Password Request

[Riley Shott]

If you'd like Dropbox to stop asking for Administrator password upon its first launch, append the following as a post-install script:

https://github.com/Ginja/Admin_Scripts/blob/master/dropbox_helper.rb

All this script does is place the file Dropbox needs in order to modify folder/file icons (/Library/DropboxHelperTools/DropboxHelperInstaller). This file, that has its SUID bit set, is executed the first time a user launches Dropbox. The end result of its execution is that a folder gets created in '/Library/DropboxHelperTools'  with the following name format:

dropbox_u[user_id_here]

And inside are the following extracted tgz:

/Applications/Dropbox.app/Contents/Resources/DropboxBundle.bundle.tgz

/Applications/Dropbox.app/Contents/Resources/FinderLoadBundle.tgz

/Applications/Dropbox.app/Contents/Resources/dbfseventsd.tgz

I've tested it throughly but if you come across any issues please let me know. This was a tag-team discovery between Brian Warsing and myself.

-Riley

[Joseph Rafferty]

This is for version 2.0?

--
You received this message because you are subscribed to the Google Groups "munki-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to munki-dev+...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Timothy Sutton]

Nice. Dropbox updates itself frequently, and there's no known (to me, at least) way to disable this behaviour.

Depending on how it does this, the user might need permissions to replace the entire Dropbox.app bundle, and therefore write permissions to /Applications. Have you run into issues with this, testing with a known older version that would automatically upgrade to something newer given enough time?

I'm not sure how one can manually initiate an update check/upgrade within the app, but I believe there's a server-side setting in the account panel, "Include me on early releases".


-Tim

[Erik]

I'm not sure how one can manually initiate an update check/upgrade within the app, but I believe there's a server-side setting in the account panel, "Include me on early releases".

You can't from the app.

https://www.dropbox.com/help/13/en

If you don't have the latest version yet, don't worry! Auto-upgrades are rolled out over the course of several weeks after a new update is available. We're very conservative about auto-updating. We never want to risk breaking a working version of Dropbox.

For our advanced users

Manually upgrading

If you haven't been upgraded (or aren't sure) and you're ready to go, simply install the latest version of Dropbox from the install page.

 

[Riley Shott]

I tested this with version 2.0 and it should work for prior releases but if you find it doesn't, let everyone know.

I haven't run into any issues with Dropbox auto-updating itself but I've also never seen/investigated it. Usually we upload the new release when Munkiserver tells us there is an update (after testing, of course). So I suspect we're beating Dropbox to the punch.

-Riley

----- Original Message -----
> From: "Erik" <eriknico...@gmail.com>
> To: munk...@googlegroups.com
> Sent: Saturday, 30 March, 2013 11:11:35
> Subject: Re: [munki-dev] Fixing Dropbox Admin Password Request
>
>
>
>
> I'm not sure how one can manually initiate an update check/upgrade
> within the app, but I believe there's a server-side setting in the
> account panel, "Include me on early releases".
>
>
>
> You can't from the app.
>
> https://www.dropbox.com/help/13/en
>
>
>
>
>
> If you don't have the latest version yet, don't worry! Auto-upgrades
> are rolled out over the course of several weeks after a new update

> is available . We're very conservative about auto-updating. We never

> want to risk breaking a working version of Dropbox. For our advanced
> users
>
>
> Manually upgrading
>
>
>
>
>
> If you haven't been upgraded (or aren't sure) and you're ready to go,
> simply install the latest version of Dropbox from the install page .
>

[A.E. van Bochoven]

Nice find, 

Creating the script indeed prevents dropbox from popping up the admin dialog. I rewrote your ruby script to a bash four liner.

However..

 I'm not so sure that creating a binary with SUID set is such a good idea. I don't know what is in the binary, security wise this is a possible timebomb. I can imagine that this it could be used as a local privilege escalation.

I think I'd rather disable the dropbox helper like I did before. Unfortunately the previous methods don't work anymore, it would be nice if there was a pref item that we could use to not install the Finder integration.

-Arjen

[Timothy Sutton]

Just put 2.0.6 on a fresh test system and let it do its thing with me authorizing its helper installer manually, as UID 501.

The following three files were configured with suid, all owned by root:wheel:

/Library/DropboxHelperTools/DropboxHelperInstaller
/Library/DropboxHelperTools/Dropbox_u501/FinderLoadBundle
/Library/DropboxHelperTools/Dropbox_u501/dbfseventsd

The binary in the mach inject bundle has "standard" 755 executable permissions. I assume the first one is what goes to set up and set the SUID bit on the second two.


-Tim

[A.E. van Bochoven]

If you don't want Dropbox insert the finder stuff, you could remove all .tgz files:

rm /Applications/Dropbox.app/Contents/Resources/*.tgz

this will prevent the admin popup, but break codesigning.
I just found out that setting the mode to 0000 on the tgz files prevents the admin dlog, and preserves codesigning:

chmod 0000 /Applications/Dropbox.app/Contents/Resources/*.tgz
codesign -vvvv /Applications/Dropbox.app
/Applications/Dropbox.app: valid on disk
/Applications/Dropbox.app: satisfies its Designated Requirement

Dropbox 2.0.6 only tested in Mountain Lion 10.8.3

-Arjen

[Timothy Sutton]

I've successfully installed 2.0.5 on my workstation without any prompts using Riley's script and a standard .app-from-dmg installation with Munki, and will wait to see what happens when it tries to self-update in the next few days. Dropbox.app and these support files are all owned by root, so if the Dropbox process (run as me) is actually what tries to do the update, not going to get so far..


-Tim

[Riley Shott]

AFAIK, Dropbox won't touch these files unless they change how they customize the Finder, so I suspect updates will go smoothly but I'm also monitoring this. Like Tim, I'm leaving my machine to auto-update from 2.0.5 to 2.0.6. Having the SUID is mandatory for Dropbox to modify the Finder and as Tim also pointed out, it's what Dropbox does when you configure it manually. I don't think it's much of security concern either as the binary doesn't have any options you can call with it. It exists only for one purpose, and that is to create a Dropbox helper folder for a user.

-Riley

----- Original Message -----
> From: "Timothy Sutton" <t...@synthist.net>
> To: munk...@googlegroups.com
> Sent: Thursday, 11 April, 2013 14:05:39
> Subject: Re: [munki-dev] Fixing Dropbox Admin Password Request
>

[Marnin Goldberg]

FYI,

I talked to Dan Levine (bio: Platform @ Dropbox) about this issue and
showed him this thread. He passed it to engineering and they came back
with:

"We've talked about it and we believe this answer is appropriate:"

Nice work Riley and Brian.


Marnin

[Timothy Sutton]

A few weeks ago I installed 2.0.5 using a standard copy_from_dmg .app Munki pkginfo, with the only addition being Riley's Ruby script. The .app bundle therefore has root:admin ownership.

A couple weeks ago 2.0.8 was released. I was away from my work machine yesterday, and today I arrived to it running 2.0.8. However, the command was not running with the bundle at /Applications, it was running from a new copy in my user's library:

Output from ps:
/Users/tsutton/Library/Application Support/Dropbox/Dropbox.app/Contents/MacOS/Dropbox /firstrunupdate 15133

So when it decides to update, it would seem to transparently stash it in the user's home instead and use that in the future.

I added a line to the postinstall_script to recursively set permissions on /Applications/Dropbox.app to 777:

FileUtils.chmod_R(0777, '/Applications/Dropbox.app')

..and re-installed on mine and a test machine. It has since updated to 2.0.8 and now to 2.0.10, all within its app bundle at /Applications, running as a non-admin. Still not obvious to me what logic will trigger an update, but my account is configured to receive new updates quickly, and it doesn't seem like it's usually taken longer than a day or even a few hours. But it seems like one could push a Dropbox config like this and not bother needing to update it again with Munki for quite a while.

More details for the curious, of the output of newproc.d when Dropbox is first launched, below. I haven't seen any behavior differences whether the /firstrunupdate flag is given or not.

84325 <82192> 32b /Applications/Dropbox.app/Contents/MacOS/Dropbox
84330 <84325> 64b sh -c LC_ALL=C /sbin/ifconfig 2>/dev/null
84329 <84328> 64b uname -p
84331 <84330> 64b /sbin/ifconfig
84326 <84325> 64b /bin/sh -c mount
84326 <84325> 64b mount
84327 <84325> 64b mount -v
84328 <84325> 64b sh -c uname -p 2> /dev/null
84333 <84325> 32b /Library/DropboxHelperTools/DropboxHelperInstaller install Dropbox /Applications/Dropbox.app/Contents/Resources/DropboxBundle.bundle.tgz
dtrace: error on enabled probe ID 5 (ID 526: syscall::mmap:return): invalid address (0x7fffbffff93c) in action #3 at DIF offset 32
84332 <84325> 32b /Library/DropboxHelperTools/DropboxHelperInstaller install Dropbox /Applications/Dropbox.app/Contents/Resources/DropboxHelperInstaller.tgz
84336 <84325> 32b /Library/DropboxHelperTools/Dropbox_u1183558739/dbfseventsd
dtrace: error on enabled probe ID 5 (ID 526: syscall::mmap:return): invalid address (0x7fffbffff948) in action #3 at DIF offset 32
84334 <84325> 32b /Library/DropboxHelperTools/DropboxHelperInstaller install Dropbox /Applications/Dropbox.app/Contents/Resources/dbfseventsd.tgz
84335 <84325> 32b /Library/DropboxHelperTools/DropboxHelperInstaller install Dropbox /Applications/Dropbox.app/Contents/Resources/FinderLoadBundle.tgz
84339 <84325> 64b /Library/DropboxHelperTools/Dropbox_u1183558739/FinderLoadBundle /Library/DropboxHelperTools/Dropbox_u1183558739/DropboxBundle.bundle 32866
84339 <84325> 64b /usr/bin/arch -x86_64 /Library/DropboxHelperTools/Dropbox_u1183558739/FinderLoadBundle /Library/DropboxHelperTools/Dropbox_u1183558739/DropboxBundle.bundle 32866
84340 <84325> 64b /usr/bin/file /Library/DropboxHelperTools/Dropbox_u1183558739/FinderLoadBundle
84341 <84325> 64b arch -x86_64 /usr/bin/osascript -s s
84341 <84325> 64b /usr/bin/osascript -s s


-Tim

[Gregory Neagle]

On May 9, 2013, at 8:49 AM, Timothy Sutton <t...@synthist.net> wrote:

> A few weeks ago I installed 2.0.5 using a standard copy_from_dmg .app Munki pkginfo, with the only addition being Riley's Ruby script. The .app bundle therefore has root:admin ownership.
>
> A couple weeks ago 2.0.8 was released. I was away from my work machine yesterday, and today I arrived to it running 2.0.8. However, the command was not running with the bundle at /Applications, it was running from a new copy in my user's library:
>
> Output from ps:
> /Users/tsutton/Library/Application Support/Dropbox/Dropbox.app/Contents/MacOS/Dropbox /firstrunupdate 15133
>
> So when it decides to update, it would seem to transparently stash it in the user's home instead and use that in the future.
>
> I added a line to the postinstall_script to recursively set permissions on /Applications/Dropbox.app to 777:

Yikes.

[Riley Shott]

Nice sleuthing, Tim. My Dropbox is taking its sweet time to update and I've also been unable to find out how to trigger it (still on 2.0.5). I don't like the idea of changing the perms to 777 but it appears that Dropbox leaves you no choice. It would be best if they adopted a process similar to Chrome, where you elect to auto-update and the rest is handled by a launchd task and, of course, all scriptable. Anyone got a contact within Dropbox's engineering team? ;)

-Riley

----- Original Message -----
> From: "Gregory Neagle" <gregn...@mac.com>
> To: munk...@googlegroups.com
> Sent: Thursday, 9 May, 2013 08:52:28
> Subject: Re: [munki-dev] Fixing Dropbox Admin Password Request
>
>

[Timothy Sutton]

Even though I did say "it seems like one could push a Dropbox config like this", I didn't mean to suggest that making the Dropbox app world-writable is the one and only solution. For many it might be fine to let it update future versions in the user's home. Greg also mentioned in ##osx-server that he's been running Dropbox out of /Users/Shared and it hasn't yet bugged him to update to a 2.x version.


-Tim

[sttsitsi]

hi guys I resolved the problem with the permissions when trying to copy into the dropbox folder by simply unistalling, cleaning any remainings from pc and registry and only then rebooting and installing on the default folder that dropbox wants to be installed and later I changed the destination and everything was alright

[Charles Fultz]

On Friday, March 29, 2013 10:37:00 PM UTC-4, Riley Shott wrote:

If you'd like Dropbox to stop asking for Administrator password upon its first launch, append the following as a post-install script:

https://github.com/Ginja/Admin_Scripts/blob/master/dropbox_helper.rb

All this script does is place the file Dropbox needs in order to modify folder/file icons (/Library/DropboxHelperTools/DropboxHelperInstaller). This file, that has its SUID bit set, is executed the first time a user launches Dropbox. The end result of its execution is that a folder gets created in '/Library/DropboxHelperTools'  with the following name format:

dropbox_u[user_id_here]

There has to be a better solution to this. On a multi-user machine (i.e. computer lab at a school), this means /Library/DropboxHelperTools/Dropbox_u<UID> is created for each user. It also means that each user either has to be an administrator (not ideal) or that someone with administrator access must go machine-to-machine and enter an administrator's password (also not ideal).

What would be ideal would be to have Dropbox packaged as an Installer PKG, whose install scripts creates things properly once, the first time, for all users (i.e. /Library/DropboxHelperTools with all bundles and binaries in it).

[Gregory Neagle]

Perhaps, but this would be the wrong place to advocate for that -- you'd want to contact the people at Dropbox...

-Greg

[Riley Shott]

> There has to be a better solution to this. On a multi-user machine
> (i.e. computer lab at a school), this means
> /Library/DropboxHelperTools/Dropbox_u<UID> is created for each user.

What's wrong with this? It's just how Dropbox functions.

> It also means that each user either has to be an administrator (not
> ideal) or that someone with administrator access must go
> machine-to-machine and enter an administrator's password (also not
> ideal).

Users don't need to be an administrator. The script takes care of what the user needed admin for.

> What would be ideal would be to have Dropbox packaged as an Installer
> PKG, whose install scripts creates things properly once, the first
> time, for all users (i.e. /Library/DropboxHelperTools with all
> bundles and binaries in it).

Completely agree, but it's not how Dropbox packaged their application and we have to work with that. I agree with Greg, you should bring it up with someone at Dropbox if you'd like to see it changed. However, they most likely are using a drag-and-drop type installer because it's faster, and easier for users to understand.

-Riley