I need to sandbox Mozilla Firefox and it seems that write access is required for "~/Library/Application\ Support/Mozilla/Extensions/" on Mac OS. I want to turn off this feature.
Is it possible somehow to disable access to "~/Library/Application\ Support/Mozilla/Extensions/", i.e in a way disabling access to global extensions. Perhaps a preference of some sort?
For reference, this is the directory for externally installed extensions on Mac OS X. From what I can tell, the write access to this directory is very limited - Firefox is merely trying to ensure that this directory exists (and a failure is ok). After that it will accept any extensions installed in this directory but will not try to write to it.
As to disabling this functionality: the directories are determined by nsXREDirProvider.cpp, the only way to disable them there would be the --disable-system-extension-dirs compile option.
But XPIProvider.jsm where these directories are used has additional logic to decide which install scopes will be used, based on extensions.enabledScopes preference. This preference doesn't exist by default, it needs to be created as an integer. Setting it to 1 will leave only the profile directory as extension source, all global extension sources will be disabled (including XREUSysExt that you are asking about - that one falls into SCOPE_USER category).
Related
The Gentoo's ebuild mecanism comes with several built-in eclasses/commands to manage (amongst others) libraries, binaries, executables, etc... Some of them are really useful to work at installation phase, like setting permissions, modifying the default installation directory, etc...
About library installation, the ebuild documentation says :
dolib [list of more libraries]
Installs a library or a list of libraries into DESTTREE/lib. Creates all necessary dirs.
libopts [options for install(1)]
Can be used to define options for the install function used in the dolib functions. The default is -m0644.
The same is available for "executables": exeopts works with doexe.
Question
The thing I really don't understand is that why dobin and dosbin exist but not binopts and sbinopts?
Is it possible have libopts or exeopts equivalents for dobin and dosbin, to manage permissions at installation phase?
Because dobin and dosbin are special cases of doexe, which have pre-defined options; if you need special permissions (e.g. suid) you can use doexe as needed.
Effectively (/usr)/bin and (/usr)/sbin should be executable to all users, unless something special (like limiting access to a group that has access to the hardware) is needed.
(I would probably be in favour of removing libopts too, but that's a different story, I guess.)
On Windows, Stack uses %AppData/stack as its storage directory by default. Is there a way to change that? I've only managed to move executables (by setting local-bin-path in the global config.yaml file), but I'd like all GHC versions, compiled packages, etc. to be stored somewhere else.
This isn't currently supported, but it should be fairly straightforward to add. I've added a ticket for it here: https://github.com/commercialhaskell/stack/issues/2067
The relevant code is here https://github.com/commercialhaskell/stack/blob/6f7871b893de2792ad9b9a02d934dfa72f8d9090/src/Stack/Config.hs#L266
I want to allow all users to read and write in a file, through my application. The file is common to all users. Where should I put that file in Windows 7?
You can use the Known Folders.
If users don't need to see the files the you can use:
FOLDERID_ProgramData - default location will be "c:\ProgramData"
If the user needs to be able to browse and find the file then the "Public" user can be used. Either FOLDERID_Public or FOLDERID_PublicDocuments. That will default to "c:\users\Public*"
You can check the list of all the standard Known Folders to see if there is anything that would work better for you. This page has the same list with friendly descriptions on how they should be used.
Use the function SHGetKnownFolderPath to get the path on the current system. Don't assume the default values are valid.
If you need this to run on Windows XP then use the previous function SHGetFolderPath and equivalent CSIDLs.
I have installed Firefox extension by double clicking abc.xpi file. Now I want to know where those files are copied, so that I can delete them. Or any other way to uninstall an extension except by going to Addons & then uninstalling it manually. I want to uninstall it programmatically.
The files created as part of the extension installation process are stored within the Firefox profile which you were using at the time. If you aren't aware of setting up more than one profile, you're probably using the "default" one which you got when you installed Firefox. Messing around with stuff within the profile directory can be extremely unwise, but if you want to try it you might want to think about:
locating the profile directory - this will depend on your operating system, but looking under the directory specified in the environment variable USERPROFILE would be a good start
finding the id for the extension you wish to remove
removing the subdirectory corresponding to the extension id under the extensions directory within the profile
remove the reference to the extension from the extensions.ini file
possibly remove the extensions.rdf file completely, to allow it to be regenerated
I am currently unaware of an automated way of doing this from the command line, if you don't want to do it yourself, but there might be tools out there to do it for you.
I found a thread on the Microsoft Forums where the answer tells how to set directory permissions using the LockPermission table. I tried it, but it doesn't seem to set the inheritance for any of the subdirectories. I need to be able to set the permissions for a particular folder that I create and have those permissions be inherited by all of the files and directories within and beneath it. Is there a way to do this without having to add a line in the LockPermission table for each and every directory (and file) that I want to affect?
For anyone looking to know the joys and pains of using MsiLockPermissionsEx, here is a tutorial, some best practices and a helper script. The helper script extracts SDDL from existing system resources - so you just use Regedit and Windows Explorer to set permissions and the helper script extracts them for you.
The article also discusses the challenge of supporting XP and Windows 7 permissions with a single package.
You can check it out here: http://csi-windows.com/toolkit/csigetsddlfromobject
You can either see if the MsiLockPermissionsEx support in MSI 5 handles this (and is an acceptable dependency for you as currently it's only available on Windows 7), or you can implement custom support. The LockPermissions support available in earlier versions of Windows Installer has the limitation you describe (and others).