Closed Bug 758477 Opened 8 years ago Closed 4 years ago

Cannot launch applications on OS X installed by another user into the global /Applications directory

Categories

(Firefox Graveyard :: Web Apps, defect, P2)

15 Branch
x86
macOS
defect

Tracking

(firefox16 wontfix)

RESOLVED WONTFIX
Tracking Status
firefox16 --- wontfix

People

(Reporter: jsmith, Assigned: marco)

References

Details

Attachments

(1 file)

Steps:

1. Install the latest nightly build
2. Go to marketplace.mozilla.org --> login --> install a free app
3. Note that the app has appeared in your applications directory
4. Logout of this account on your OS system
5. Login with a different account on this OS system
6. Launch the application previously installed

Expected:

The application should be able to be launched, given that the application is in the global /Applications directory on Mac.

Actual:

An error is reported saying "Error - Unable to parse environment files for application startup." In some other cases, I've also seen "Unable to Update - Failed preparation for runtime update." I'm wondering if the two error messages are two separate problems. However, both lead to not letting the app be able to be launched.
Nominating for k9o - this is highly problematic for any family that decides to use web apps on a single computer with multiple accounts (or basically any scenario with multiple accounts to a computer).
blocking-kilimanjaro: --- → ?
Severity: critical → normal
Priority: -- → P2
Target Milestone: --- → Firefox 15
Myk - Could you explain why this is a P2 and not critical? This sounds pretty bad IMO, as this really causes a burden to any scenario in which a computer is used by multiple users. An example - family computers with multiple accounts. What happens as a result is you end up with /Applications directory with apps in there created by various accounts, but only usable by the account that created it. So you can expect many scenarios where I go, "Hey, I see that have this app installed that someone else installed, let me try it out!" - And I end up with being unable to launch the app all-together, resulting a bad error message.

May be good to get data on this to better understand the priority (got a strong feeling we've got the data somewhere). Margaret - How often are apps installed by one user used by another user on the same computer? Is it a likely use case? Less likely? Generally trying to figure out the likelihood of the user scenario described in this bug would occur.
Target Milestone: Firefox 15 → ---
Question to Product: How many users do we expect to be affected by this bug?
Keywords: productwanted
(In reply to Brad Lassey [:blassey] from comment #3)
> Question to Product: How many users do we expect to be affected by this bug?

Emailed Margaret about this, here's the response:

Hi Jason,

While I don't have precise data to answer your question, and the market requirements are still being finalized, my take right now is that the likelihood would be on the low end. The percentage of people who share devices in developed markets is not high. And in emerging markets where people frequent cyber cafes with shared computers, our primary focus will be on mobile devices that are not typically shared.

Hope this helps.

Margaret 

On this basis, this probably does not block k9o, although definitely probably still makes sense to keep at a P2, given the severity of the bug.
blocking-kilimanjaro: ? → ---
Keywords: productwanted
QA Contact: jsmith
Duplicate of this bug: 791810
I reported a similar problem in bug 791810: a user without admin privileges cannot install or launch any webapp.
It's not about several people sharing the same computer, it's about one person that uses a limited user account for security reasons. On this account, any action requiring admin privileges (installing an app is the most frequent) generates a popup asking login and password to a root account. That's a normal and expected behaviour.
Firefox should have the same behaviour when trying to install an app.

Or Firefox could install the web app in the /Applications folder of the current user, therefore avoiding the problems of the user's rights (FYI, that's what Steam does).
The problem is that the user without admin privileges can't modify files in the /Applications directory, so the runtime fails to update.
Well, as I said previously, web apps could be installed in the user's application folder (~/Applications). They would not require any privileges and would only be available for the current user. It would be an acceptable workaround. Transparent for a user with admin privileges and allows simple users to finally get webapps to work.

I would be very happy to help testing if a patch lands.
And in the case the runtime doesn't need to be updated, the runtime can't read the webapp.ini file (thus "Error - Unable to parse environment files for application startup.") because it's readable only by its owner.

Also, the packages installed by an user look broken for other users because the Info.plist is readable only by its owner.
We actually also have the problem that the webapp runtime will try to use the webapps registry in the profile directory of the user that installed the app.

Looks like installing in the user applications directory is the only viable option.
Depends on: 901757
Assignee: nobody → mcastelluccio
Status: NEW → ASSIGNED
If the update fails, launches the application anyway (this is needed because unprivileged users can't modify files in the /Applications folder).

The other error ("Error - Unable to parse environment files for application startup.") will be fixed by bug 901757.
Attachment #786079 - Flags: review?(myk)
Notice that since we shipped the feature we have never allowed unprivileged users to install/use applications, so we'll likely need to fix other problems.
Comment on attachment 786079 [details] [diff] [review]
fix_mac_webapprt_update

Review of attachment 786079 [details] [diff] [review]:
-----------------------------------------------------------------

(In reply to Marco Castelluccio [:marco] from comment #9)
> And in the case the runtime doesn't need to be updated, the runtime can't
> read the webapp.ini file (thus "Error - Unable to parse environment files
> for application startup.") because it's readable only by its owner.
> 
> Also, the packages installed by an user look broken for other users because
> the Info.plist is readable only by its owner.

It looks like this patch doesn't change the file permissions for these files.  Have you done so elsewhere?  We should fix those too so they're accessible to the other user.


(In reply to Marco Castelluccio [:marco] from comment #10)
> We actually also have the problem that the webapp runtime will try to use
> the webapps registry in the profile directory of the user that installed the
> app.

This is a general issue with our model, which combines native app installation on multi-user OSes with a user/profile-specific app registry.  But we should tackle it separately, since it's orthogonal, as the runtime doesn't require the registry to run apps.


Unfortunately, this patch is not going to work, because libxul is not binary-compatible across Firefox versions, so it isn't possible for the webapprt stub from one Firefox version to load the libxul from another.

bsmedberg may have a better idea, but I think the right thing is to prompt the user to authorize the update using the Mac APIs for requesting such privileges.  See Apple's Elevating Privileges Safely document (and authopen specifically) for details:

http://developer.apple.com/library/mac/documentation/Security/Conceptual/SecureCodingGuide/Articles/AccessControl.html
http://developer.apple.com/library/mac/documentation/Security/Conceptual/SecureCodingGuide/Articles/AccessControl.html#//apple_ref/doc/uid/TP40002589-SW5
Attachment #786079 - Flags: review?(myk) → review-
(In reply to Myk Melez [:myk] [@mykmelez] from comment #13)
> It looks like this patch doesn't change the file permissions for these
> files.  Have you done so elsewhere?  We should fix those too so they're
> accessible to the other user.

Yes, bug 901757.

> Unfortunately, this patch is not going to work, because libxul is not
> binary-compatible across Firefox versions, so it isn't possible for the
> webapprt stub from one Firefox version to load the libxul from another.

Yes, this was my concern.

> bsmedberg may have a better idea, but I think the right thing is to prompt
> the user to authorize the update using the Mac APIs for requesting such
> privileges.  See Apple's Elevating Privileges Safely document (and authopen
> specifically) for details:
> 
> http://developer.apple.com/library/mac/documentation/Security/Conceptual/
> SecureCodingGuide/Articles/AccessControl.html
> http://developer.apple.com/library/mac/documentation/Security/Conceptual/
> SecureCodingGuide/Articles/AccessControl.html#//apple_ref/doc/uid/TP40002589-
> SW5

This is a little unfortunate, for every Firefox release (six weeks?) the user would be prompted to insert the admin credentials in order to launch the application.
Depends on: 906223
Depends on: 905881
(In reply to Christopher Van Wiemeersch [:cvan] from comment #15)
> I just reproduced this on Mac OS X 10.9.5
> 
> https://www.dropbox.com/s/jm0mumoyu1jzct1/Screenshot%202014-10-16%2023.23.24.
> png?dl=0
> 
> but I *am* the owner:
> 
> https://www.dropbox.com/s/jemzfixwn0owbmf/Screenshot%202014-10-16%2023.23.40.
> png?dl=0

This might be a regression from the v2 signing work.
(In reply to Marco Castelluccio [:marco] from comment #16)
> (In reply to Christopher Van Wiemeersch [:cvan] from comment #15)
> > I just reproduced this on Mac OS X 10.9.5
> > 
> > https://www.dropbox.com/s/jm0mumoyu1jzct1/Screenshot%202014-10-16%2023.23.24.
> > png?dl=0
> > 
> > but I *am* the owner:
> > 
> > https://www.dropbox.com/s/jemzfixwn0owbmf/Screenshot%202014-10-16%2023.23.40.
> > png?dl=0
> 
> This might be a regression from the v2 signing work.

Indeed, that would be bug 1064910.

cvan: it sounds like your situation is a bit different from this bug.  Can you file a new one and cc: Marco and :spohl and me?
Blocks: 1111077
Per bug 1238079, we're going to disable the desktop web runtime and remove it
from the codebase, so we won't fix these bugs in the integration between Firefox and the runtime.
Status: ASSIGNED → RESOLVED
Closed: 4 years ago
Resolution: --- → WONTFIX
Product: Firefox → Firefox Graveyard
You need to log in before you can comment on or make changes to this bug.