1730898 - Silent update is performed on a non-installer admin without being installed manually before by elevation

Status: RESOLVED INVALID

(Toolkit :: Application Update, defect)

Description

[Hani Yacoub, Desktop QA]

Affected versions

Firefox 93.0b1

Affected platforms

macOS 10.14
macOS 10.15
macOS 11.04

Steps to reproduce

1. Login to Admin 1 and install Firefox 93.0b1
2. Set Up An Update Server to update Firefox to Firefox 93.0b2
3. Go to: Firefox → About Firefox to initiate an update check
4. Close the window opened before
5. Close Firefox from the x button
6. Wait ~5 minutes for the updates to be downloaded and installed silently.
7. Firefox is updated to Firefox 93.0b2
8. Switch to Admin 2
9. Set Up An Update Server to update Firefox to Firefox 93.0b3
10. Go to: Firefox → About Firefox to initiate an update check
11. Close the window opened before
12. Close Firefox from the x button
13. Wait ~5 minutes

Expected result

• NO Updates are made after ~5 min.
• NO Update UI is displayed.
• NO Window is opened

Actual Result

• The Updates are silently downloaded and installed after ~5 min.
• NO Update UI is displayed.
• NO Window is opened

Note

• If we didn't set up an update server to update Firefox to Firefox 93.0b2 with the first admin (from step 2 to step 7) , silent update was performed only after an elevation installation was made.

Comment 1

[Robin Steuber (she/her) [:bytesized] (Out until April 4)]

This seems a bit unexpected but, since no UI was shown, it doesn't really sound like a problem.

I mean, ideally we actually want to be able to install updates in this situation, it just shouldn't really be possible. The reason that it shouldn't be possible is that the default permissions on the installation don't usually allow it to be updated by anyone except for the installing user. Once we run an install with elevation (which requires showing UI), we change the permissions such that we should be able to install further updates without elevating again. So, presumably this is happening because the default permissions already allow other administrators to update. Like I said, this is unexpected, but not really bad.

I would like to delve into this a bit further though. Could you run through this test again and check the permissions at a couple of different points for me? I would like to see what the permissions are on the application after step 1, after step 7, and at the end of the test. You can check the permissions by opening a Terminal and running ls -ld <install location>.

For example, I have an installation right now that looks like this:

> ls -ld /Applications/Firefox.app
drwxrwxr-x@ 3 ksteuber admin 96B Sep 10 18:59 /Applications/Firefox.app

But the default permissions usually look more like this:

> ls -ld /Applications/Firefox.app
drwxr-xr-x@ 3 ksteuber admin 96B Sep 10 18:59 /Applications/Firefox.app
#    ^--- Notice that this is a '-' instead of a 'w'

Since the group write permission is missing, I should only be able to write to this directory as the user ksteuber. But when that group write permission is present, any admin user should be able to write to the directory, and thus install updates.

If you are able to update in this situation, I'm guessing that the permissions started out with that group write permission present. I'm not really sure why this would be, but it wouldn't be the first inconsistency I've seen with default application permissions. For example, I've seen the default group be admin, staff, and wheel. I'm not really sure why this happens. But as long as we aren't showing any unexpected UI, it's not really a big deal.

It would be good to resolve this though, because otherwise I'm not sure that we are going to get the testing that I want on ensuring that no UI is shown in situations where elevation would normally be required.

Could you also tell me what your procedure is for removing the old installation and installing a new one when you finish one test and start another one? It's possible that that could be related. Thanks!

Comment 2

[Hani Yacoub, Desktop QA]

I run through this test again and checked the permissions:
After step 1: drwxr-xr-x 3 yacoub.hani admin 96 Sep 6 21:36 /Applications/TEST.app
Afer step 7: drwxrwxr-x 3 yacoub.hani admin 96 Sep 22 12:25 /Applications/TEST.app
After the last step: drwxrwxr-x 3 yacoub.hani admin 96 Sep 22 12:42 /Applications/TEST.app

I usually remove an old installation by right click on the app from application and move it to bin.
I install Firefox from: https://archive.mozilla.org/pub/firefox/candidates/93.0b1-candidates/build1/mac/en-US/
double click on the dmg file downloaded and then move it to application.

Please let me know if further investigations are required.
Thanks.

Comment 3

[Robin Steuber (she/her) [:bytesized] (Out until April 4)]

Ah! I think I have found why this can happen, but doesn't always happen. As I mentioned before, the group that owns the installation directory by default does not seem consistent. It seems to be possible for it to be admin, staff, or wheel for unknown reasons.

When we do an elevated update, we set the group ownership of the installation directory to admin and enable the group write permission so that we can perform future updates from any administrator account without needing elevation. This happens here.

But there is another part that I wasn't aware of. After we've done the elevated bit once, we always update the permissions to stay like this so that we don't lose the group write permission during the course of the update (here). But the way that we check if we've done this already is by checking if the group ownership is admin. Since this is sometimes the default, sometimes this happens on update without an elevated update ever happening.

This appears to be what is happening in your case. You can see that the permissions are as-expected after step 1, and you do indeed start out with the group owner set to admin. And then after step 7, you have that group write permission set.

I'm going to go ahead and close this bug since I now understand this behavior and it seems to be perfectly acceptable. My only other concern was whether the code paths that I care about still got tested given the unexpected behavior in this test case. But I just reviewed the list of test cases, and it looks like there are other ones that cover the relevant code paths. So we should be all good here.