Closed Bug 580705 Opened 14 years ago Closed 14 years ago

"/Library/Application Support/Mozilla", wrong ownership and permissions

Categories

(Toolkit :: Add-ons Manager, defect)

1.9.2 Branch
x86
macOS
defect
Not set
minor

Tracking

()

VERIFIED FIXED

People

(Reporter: spamcop, Unassigned)

Details

I just noticed that Firefox creates the following folder:

"/Library/Application Support/Mozilla"

With a sub-folder Extensions, having a sub-folder being a UUID, but there are no files inside. Please note, I'm not talking about the user Library folder here (~/Library), I'm talking about the system wide library folder here.

There is nothing wrong with an application creating a user wide AppSupport folder, as long as you consider, that only admin users can write to that directory (folder is 775 and root:admin), so this folder must not be critical for using Firefox to allow non-admin users to use it.

The problem is that the Mozilla folder has wrong permissions. It should have 775 and belong to root:admin (just like AppSupport itself), but it has 755 and it belongs to myself; only the group is correct. That way not even other admin users will be able to write something to this folder, because group has no write permissions. Same applies to all sub-folders found inside.

I understand that you cannot easily make the folder belong to the root user, because therefor you'd needed to authenticate the user as admin and then run a helper tool with root privileges; however, you could at least give the admin group write access to this folder.

On the other hand, I wonder what this folder is good for. Unless it really servers a good purpose, I'd stop creating it altogether. If it is just to have system wide extensions, users can create this folder by hand, if this is really desired. It would be enough to document this possibility somewhere. And even in that case, the structure should not be Mozilla/Extensions, but wost likely "Firefox/Extensions", unless extensions installed there shall also apply to e.g. Thunderbird. If you want to group all your products there, better use Mozilla/Firefox/Extension and Mozilla/Thunderbird/Extension, etc.

This is no security risk or anything, it just means that other admins of my systems cannot access a folder, that should always be accessible to admins (they must use sudo to modify the folder or its content). And it's a little bit of a privacy issue, since I might have Firefox in my encrypted home directory (and not in /Applications) and nobody needs to know, that I'm using Firefox on the system, but they will know, because this directory is owned by me.

Just deleted it and restart Firefox and it gets created exactly the same way. So this is not a left over from a very old Firefox version I might have once tested, it happens with the latest version as well.
Component: General → Add-ons Manager
Product: Firefox → Toolkit
QA Contact: general → add-ons.manager
Version: 3.6 Branch → Trunk
timeless-mbp timeless$ ls -hal /Library/Application\ Support/Mozilla/Extensions/
total 0
drwxr-xr-x@ 6 timeless  admin   204B Jun  7 20:54 .
drwxr-xr-x@ 3 timeless  admin   102B Feb 24 21:11 ..
drwxr-xr-x  2 timeless  admin    68B Apr 12 17:22 {a23983c0-fd0e-11dc-95ff-0800200c9a66}
drwxr-xr-x  2 timeless  admin    68B Jun  7 20:54 {a463f10c-3994-11da-9945-000d60ca027b}
drwxr-xr-x  2 timeless  admin    68B Mar  2 11:19 {b1042fb5-9e9c-11db-b107-000d935d3368}
drwxr-xr-x@ 2 timeless  admin    68B Feb 24 21:11 {ec8030f7-c20a-464f-9b0e-13a3a9e97384}

So my last instance of this was Jun 7.
Version: Trunk → 1.9.2 Branch
THink this is a dupe but I cant find it right now. This was fixed by the patches in bug 553169, we no longer automatically create these directories.
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
i couldn't find code in trunk. thanks for the explanation
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.