http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7804
Chris Nighswonger <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |[email protected] | |u --- Comment #29 from Chris Nighswonger <[email protected]> --- (In reply to comment #25) > > As for why I think this is necessary, consider a plugin which is nothing but > > a one-line forkbomb. Having an executable file doesn't even require someone > > to follow an API. They can simply download one of the gazillion of examples > > of how to take down your server with one line (just, what, 9 characters if > > you're using bash?), zip it up with your example ini file, and bring down > > the server. Or a plugin which actually just contains a command line script > > for reinitializing your Koha database for testing. Accidentally zip that up > > with your plugin, have someone connect to it (and there's no need for > > authentication to access a plugin, notice!), and your production server is > > pristine. Like the cheese shop, it is very clean. > > I understand your examples, but I feel like this is more of a buyer beware > issue. If you are uploading random plugins to your system without vetting > them first, then of course you will have problems, Module::Load::Conditional > or not! Speaking as a sysadmin, I never run software with known security holes such as this one. Its just another hole-in-the-wall I have to try to be conscious of amongst the zillion or so I'm not even aware of. Producing code with security holes in ignorance is forgivable; producing code with security holes in full knowledge borders on the unethical imho. -- You are receiving this mail because: You are watching all bug changes. _______________________________________________ Koha-bugs mailing list [email protected] http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
