10.6 and 10.8 machines don't have enough privileges to write to /Applications

RESOLVED WONTFIX

Status

Release Engineering
Platform Support
RESOLVED WONTFIX
4 years ago
4 years ago

People

(Reporter: marco, Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

4 years ago
I'm working on some tests for apps installations and updates. On Mac apps are installed in the /Applications directory.
On 10.6 and 10.8 try machines we don't have enough privileges to write to this directory, so the tests are always failing.

Comment 1

4 years ago
Hi Marco,
Which privileges are you talking specifically about? File permissions? The user running the jobs?

Would loaning a 10.6 and 10.8 machine help determine what is require to make your tests pass on them?
(Reporter)

Comment 2

4 years ago
The nsIFile::isWritable function returns false, so I think the user running the jobs doesn't have write privileges for the /Applications directory.
I think only admin users can write to that directory.

We currently support apps installation on Mac only for privileged accounts (and this is what I'm testing). Users without admin privileges can't currently install apps.

Comment 3

4 years ago
Would you be able to borrow a 10.6 machine and verify this?
When could you do so?

On another note, is this not an issue for Linux and Mac?

Have we considered install WebApps in another location?
Do we know how many of our users are Administrators?
(Reporter)

Comment 4

4 years ago
(In reply to Armen Zambrano [:armenzg] (Release Engineering) (EDT/UTC-4) from comment #3)
> Would you be able to borrow a 10.6 machine and verify this?
> When could you do so?

The problem was already verified (see bug 791810).

> On another note, is this not an issue for Linux and Mac?

On Linux and Windows we install applications in directories that don't need privileges (on Linux in the home directory, on Windows in the AppData directory).

> Have we considered install WebApps in another location?

In bug 791810 I've tried installing the app in the user's applications directory, but there is a side effect.
In the long run I think we'll raise the privileges when needed.

> Do we know how many of our users are Administrators?

I think most Mac users only use a single account that has Admin privileges, but I don't have any data to support this statement.

Comment 5

4 years ago
(In reply to Marco Castelluccio [:marco] from comment #4)
> (In reply to Armen Zambrano [:armenzg] (Release Engineering) (EDT/UTC-4)
> from comment #3)
> > Would you be able to borrow a 10.6 machine and verify this?
> > When could you do so?
> 
> The problem was already verified (see bug 791810).
> 
Could you please try to verify that changing the user type in our infra would solve the problem?
I would like that to be verified before moving forward on changing the whole pool of machines.

> > On another note, is this not an issue for Linux and Mac?
> 
> On Linux and Windows we install applications in directories that don't need
> privileges (on Linux in the home directory, on Windows in the AppData
> directory).
> 
> > Have we considered install WebApps in another location?
> 
> In bug 791810 I've tried installing the app in the user's applications
> directory, but there is a side effect.
> In the long run I think we'll raise the privileges when needed.
> 
Can the side effect be overcome? 
Any way to make the OS not to think that the application is installed for all users?

FTR from the bug mentioned:
"the unfortunate side effect that the operating system thinks the application is installed for all the users..."

> > Do we know how many of our users are Administrators?
> 
> I think most Mac users only use a single account that has Admin privileges,
> but I don't have any data to support this statement.

I have the same assumption.

Comment 6

4 years ago
(In reply to Armen Zambrano [:armenzg] (Release Engineering) (EDT/UTC-4) from comment #5)
> FTR from the bug mentioned:
> "the unfortunate side effect that the operating system thinks the
> application is installed for all the users..."
> 

What does this cause? Other users might try to run the app from their account and fail? I assume that would be expected. A user should not be able to run the apps of another user.

Would the original user that installed unto its personal App directory be OK? If so, it seems that we would be fine.

This is from a convo with other team members:
> Once this privilege is granted [making the CI user be Administrator],
> there is no way to ensure
> the same initial state between runs without a re-image. <= this is huge
> imo and potentially impacts every other test. Also, the 2nd invocation
> on the same tester won't be testing the identical issue.
> 
> Since this feature makes a distinction between 2 classes of users
> (admins and non-admins), and we only support one class of user in CI,
> only the condition that matches the class we support can be tested in
> CI. The other testing more properly belongs to QA.

The reasoning is that anyone with malicious intent and Try commit level could compromise these machines.
The other problem is if another dev lands bad code, it could mess up the setup of the machines and cause problems in runs in the future.

Comment 7

4 years ago
FTR, 10.7 was incorrectly setup and we're making sure that following infrastructure does not have this security and reliability flaw.
(Reporter)

Comment 8

4 years ago
The problem is that the app would be visible in the Mac launchpad by very user, but only the user that installed the app would be able to execute it.
Anyway, I think this isn't the right bug to discuss solutions to this problem (the right place would be bug 791810).

Here I'd just like to find a way to test our current code (if there's a way, otherwise we'll test only Windows and Linux).
I see there are security problems in giving admin privileges to the user running the tests (if we can't trust users with try commit level).
Maybe we could only give write privileges for the /Applications directory to the user running the tests? This way probably it wouldn't have enough privileges to do any harm.

About the reproducibility issue, the test removes all the application-related files at the beginning and at the end, so that we can ensure the same state between different runs.

Comment 9

4 years ago
Hi marco,
As much as I would like to see this running in our infrastructure, the proposed approach breaks many of the measures we have in place to ensure reliability, security and consistency of our pool.
Unfortunately, we can't be changing this in our Mac infrastructure.
Please try to come up with a different testing approach (e.g. manual QA) or try to see if there is a solution for the Mac side effect.

I hope this makes sense.
Status: NEW → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → WONTFIX
(Reporter)

Comment 10

4 years ago
(In reply to Armen Zambrano [:armenzg] (Release Engineering) (EDT/UTC-4) from comment #9)
> Hi marco,
> As much as I would like to see this running in our infrastructure, the
> proposed approach breaks many of the measures we have in place to ensure
> reliability, security and consistency of our pool.
> Unfortunately, we can't be changing this in our Mac infrastructure.
> Please try to come up with a different testing approach (e.g. manual QA) or
> try to see if there is a solution for the Mac side effect.
> 
> I hope this makes sense.

Thank you Armen!
I'll try to come up with a different solution to test the installation on Mac.
You need to log in before you can comment on or make changes to this bug.