Within /root directory, create a symlink named".mozilla" with"/dev/null" as its target.
pleasePLEASEplease add this to future releases via build-iso theme
12 posts
• Page 1 of 1
-
Posts: 1,445
- Joined: 09 Feb 2012
#1
Last edited by skidoo on 30 Aug 2016, 03:50, edited 1 time in total.
-
Posts: 1,308
- Joined: 31 Aug 2009
#2
skidoo, root being able to launch firefox has never been an issue for me. ISTM there might be some rare cases where a user might want to launch firefox as root. I can even imagine someone complaining if we include the symlink you suggest as part of our iso releases based on the principle of least surprise. I agree it is generally a bad idea but there are lots of bad things you can do as root.
Can you explain why you want this disabled by default? What are the benefits? Are you frequently launching firefox by accident when you are logged in as root?
edit: Perhaps another solution would be a little /usr/local/bin/firefox script that gives you a warning before launching firefox if it detects it was launched by root.
Can you explain why you want this disabled by default? What are the benefits? Are you frequently launching firefox by accident when you are logged in as root?
edit: Perhaps another solution would be a little /usr/local/bin/firefox script that gives you a warning before launching firefox if it detects it was launched by root.
-
Posts: 119
- Joined: 31 May 2014
#3
I don't even run FF or chromium as ME, I have a separate"browser" abUser set up w/very little privilege to do anything but run the browser by a script that su's to that user and launches the browser. See my post in Tips & Tricks entitled" Tip for Protecting your Computer from your Browser".
-
Posts: 1,445
- Joined: 09 Feb 2012
#4
Because one doesn't expect/intend to launch browser as root, one doesn't bother to setup a"profile" for root (install adblock and other extensions, tweak the prefs). When the browser unexpectedly launches, typically due to some the"Help" button within some GUI app being linked to online htmldocs... you're unprotected (in terms of adblock) and 'boom' firefox generates a fresh profile, replete with 25Mb worth of userfiles (especially unwelcome during toram live session). If you DO take the time to setup a permanent profile (install adblockPlus etc), that adds yet another 30Mb, in the form of ABP blocklists and backups...
I had written a python wrapper for firefox launcher last year & was using that. I posted an early version of the script; unsure whether I left it online or redacted it.
Also, I had set dillo to be the default handler for html/* mimetype for xdg-open... but firefox still occasionally wound up being launched. (App doesn't call xdg-open? or some mimetype(s) I missed, like image/png and application/atom+xml?)
I had written a python wrapper for firefox launcher last year & was using that. I posted an early version of the script; unsure whether I left it online or redacted it.
Also, I had set dillo to be the default handler for html/* mimetype for xdg-open... but firefox still occasionally wound up being launched. (App doesn't call xdg-open? or some mimetype(s) I missed, like image/png and application/atom+xml?)
Okay, maybe the best course is for a mod to move this thread to Tips-n-Tricks (and I'll edit the first post to remove the pleasePLEASEplease line).I can even imagine someone complaining if we include the symlink you suggest as part of our iso releases based on the principle of least surprise.
-
Posts: 1,308
- Joined: 31 Aug 2009
#5
Are these homegrown apps or apps from upstream? If it is only homegrown apps then we should fix it in the app itself. If they are upstream apps then some other solution will be needed. Thanks again.
Ah, I see. Thank you. Good explanation.skidoo wrote:When the browser unexpectedly launches, typically due to some the"Help" button within some GUI app being linked to online htmldocs... you're unprotected (in terms of adblock) and 'boom' firefox generates a fresh profile, replete with 25Mb worth of userfiles (especially unwelcome during toram live session).
Are these homegrown apps or apps from upstream? If it is only homegrown apps then we should fix it in the app itself. If they are upstream apps then some other solution will be needed. Thanks again.
-
Posts: 4,164
- Joined: 20 Feb 2009
#6
OK. __{{emoticon}}__Okay, maybe the best course is for a mod to move this thread to Tips-n-Tricks (and I'll edit the first post to remove the pleasePLEASEplease line).
-
Posts: 1,445
- Joined: 09 Feb 2012
#7
Few among the 'homegrown' apps are run as root & I can't recall any that link to remote webpages.
geany, seamonkey, etc. toolbar help buttons are the ones that have caught me offguard.
On the MX side, many (if not most) of the help buttons within dialog windows of the various xfce components lead to online docs.
antiX controlCenter } System } Edit config files
passes through to root-permissioned geany instance, but short of"going to extremes" by scripting ifdown } geany } ifup...
it would be impractical to employ guarding via wrapper scripts.
geany, seamonkey, etc. toolbar help buttons are the ones that have caught me offguard.
On the MX side, many (if not most) of the help buttons within dialog windows of the various xfce components lead to online docs.
antiX controlCenter } System } Edit config files
passes through to root-permissioned geany instance, but short of"going to extremes" by scripting ifdown } geany } ifup...
it would be impractical to employ guarding via wrapper scripts.
-
Posts: 1,308
- Joined: 31 Aug 2009
#8
Thanks skidoo. I agree this is a problem. I'm not sure what the best solution is. Your symlink to /dev/null seems reasonable but I don'tif we should spring that on people without warning. We could add a norootfirefox live boot option.
-
Posts: 1,308
- Joined: 31 Aug 2009
#9
We have not yet used up every single letter in the alphabet for our disable=xyz flag. How about disable=f to disable root firefox via the /dev/null symlink? If we do this and if you make live-usbs with the new live-usb-maker program then all you need to do is use the --cheat=disable=lxf command line parameter to make this the default for your live-usbs. You could even add CHEATS=disable=lxf to your live-usb-maker.conf file.
-
Posts: 1,445
- Joined: 09 Feb 2012
#10
Thanks, but it's fine (maybe best?) left as a Tips-n-Tricks entry.
Anyone who's interested in employing this proactive defense is more likely to find the tip post than find the cheatcode documentation.
Besides, the cheat would become ineffective if a user changes their default browser.
(I'm not gung-ho to track down symlink targets for the various names/paths of alternative browser executables.)
Anyone who's interested in employing this proactive defense is more likely to find the tip post than find the cheatcode documentation.
Besides, the cheat would become ineffective if a user changes their default browser.
(I'm not gung-ho to track down symlink targets for the various names/paths of alternative browser executables.)
-
Posts: 1,308
- Joined: 31 Aug 2009
#11
1) Adding disable=f would be a convenience for you.
2) You could always update the Tips-n-Tricks entry to mention disable=f
3) I'm in favor of seeing more happy dances around here
4) It's up to you
2) You could always update the Tips-n-Tricks entry to mention disable=f
3) I'm in favor of seeing more happy dances around here
4) It's up to you
-
Posts: 1,445
- Joined: 09 Feb 2012
#12
Again, thanks, but I've settled on"it's best left as a Tips-n-Tricks entry."
At reading your reference to"principle of least surprise", I immediately agreed.
User is best served by reading the tip and manually placing the appropriate symlink. Afterward, s/he knows the result to expect and can trust it will be consistent.
Introducing a variable (employing a cheatcode) seems less ideal because it would create"false sense of security" if someone later forgets to use/save the cheatcode (or it inadvertently gets removed from the bootline)
At reading your reference to"principle of least surprise", I immediately agreed.
User is best served by reading the tip and manually placing the appropriate symlink. Afterward, s/he knows the result to expect and can trust it will be consistent.
Introducing a variable (employing a cheatcode) seems less ideal because it would create"false sense of security" if someone later forgets to use/save the cheatcode (or it inadvertently gets removed from the bootline)