Noah, > Python lacks any form of sandboxing so if someone can manipulate > plugins they can do anything Trac can do and there is _no_ way to > prevent that.
I was wrong mentioned the word "security" in my initial letter - it's immediately bring to people mind police officers with guns etc.
Nobody expect from trac to defend the whole system from intruders but it should prevent *trac content* from being changed or exposed occasionally.
e.g (speculating, I didn't look into trac db api yet)if someone write malicious plugin accessing trac database directly (not using db api) - it's a responsibility of site admin
don't have such plugin installed.But trac developers are responsible to have db api secure and safe - for instance check user permissions inside db.api but don't require plugin developers to do it explicitly before calling api.
Another example of a security mistake trac developers should care of - is NoAnonymousPlugin and it derivatives - if something goes wrong with this plugin all private content it protects become accessible for everyone. So correct plugin should do the opposite - enable part of wiki content for visitors that do not have WIKI_VIEW permission.
-Dmitry On 2010-10-11 21:22, Noah Kantrowitz wrote:
I think there are two main issues to clarify. 1) Python lacks any form of sandboxing so if someone can manipulate plugins they can do anything Trac can do and there is _no_ way to prevent that. It is a limitation of Python and unless something like Brent Cannon's restricted interpreter work ever ends up in core making people jump through hoops (example, multiple configuration files) is pointless and annoying. 2) Trac has always and will always been designed with people running a single-environment site in mind. That isn't to say that we would never make a compromise, but things are stacked pretty heavily in favor of single-project setups since that comprises the vast majority of the userbase. A setup like you mentioned with Trac being used for SourceForge-style hosting is exceedingly rare, though it just so happens that one of most active core developers is in charge of such a site as part of his day job. I think there is also some confusion about how plugin loading works (re: the global default comment). Setuptools will examine every folder on sys.path (and $ENV/plugins and any configured plugins_dir's) looking for .egg-info folders or egg files containing EGG-INFO data. Any such package with a [trac.plugins] group in its entry points will be loaded and returned. Of note, this means that module-level code in any package that declares trac.plugins entry points will be run regardless of the enable status. I am trying to make it clear that disabling a plugin isn't meant to be a security-grade check. The only way to ensure that a plugin is running no code is to entirely remove it from the path. Using virtualenv (which all sane people running Python webapps should be using I hope) this is easy since you can just delete the offending file from that particular packages folder. The enable/disable settings only kicks in all the way down the line when iterating over an extension point. As for altering the auto-load settings, you could probably do that in a plugin without that much trouble. If you are actually interested in doing this, try finding me on the IRC channel or contact me off-list. --Noah On Oct 11, 2010, at 9:04 AM, Dmitry Samersoff wrote:Grzegorz, The most important part of proposal - multiple plugins directories counted explicitly in trac.ini and I guess it has minimal impact. i.e. we can have something like plugins_dirs = /a,/b,/c plugins_autoenable_dirs=/a,/c and keep everybody satisfied ;) (see also below) On 2010-10-11 15:45, Grzegorz Sobanski wrote:Currently nothing prevents admin of other project enable it for its own env.Hmm, just put in in envdir/plugins? Then it's not available to other environments.Unless someone "inherits" it ... There are some symlink/permissions tricks that solve this problem, but I would like to see an instant solution rather than tricks.Again, if someone already has R/W access to the env folder, you have bigger problems.e.g. A plugin developer type: cp myplugin.py myplugin_old.py and than forget to delete myplugin_old.py with plenty of debug printing.And what if he types: rm *?rm * is not an issue as it doesn't lead to security whole. Just some extra work for backup team. Also how often you here that someone did rm * on the hosting ? Incident with forgotten old or back files happens once a month and cost a fortune.Etc, etc As Noah said, if someone has fs access, or can deploy plugins developed by themselves, they can break everything.2. No autoenableThis just makes life difficult for simple, one-env sites.Really? It's either one-line in ini file or couple of mouse clicks in admin panel.A would say: sensible defaults. If someone puts a plugin in environment, he surely wants it enabled, so IMO it should be enabled by default. It's a very sensible solution.It's very sensible solution for small system where plugin developer, trac admin and web qa is the same person.Debugging issues like one with myplugin_old.py above eats much more time.But only for you, and enabling all modules would have to be done by hundreads of other people, sorry. Plus all the questions on ML "why my plugin doesn't work".We should separate trac core (i.e. controlled and supported by trac team) information from one provided by third-party, untrusted plugins to avoid possible conflicts and save support efforts.Trac doesn't sandbox plugins, so you *have to* trust plugins, because they can do everything.Yes and it's a trac design issue. But it couldn't be addressed without significant efforts, ini separation is just one simple step forward.I don't see how separating enabling modules from trac.ini helps with anything, sorry.Trac is clearly devided into core and plugins and it's one of biggest advantage of trac. i.e. if I turn off all plugins I have reasonable and secure enough environment. But bad plugin (e.g. with incorrect implementation of IAdminPanelProvider) could destroy whole project configurationI think you may have some valid points about probles in config like "trac farm", but the proposed solution IMO are not good defaults for trac, at least some of them.I never pretend to be an oracle .. Just giving to trac community a subject to think. -Dmitry -- Dmitry Samersoff d...@samersoff.net, http://devnull.samersoff.net * I do want to change the world, I don't want the world to change me -- You received this message because you are subscribed to the Google Groups "Trac Development" group. To post to this group, send email to trac-...@googlegroups.com. To unsubscribe from this group, send email to trac-dev+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/trac-dev?hl=en.
-- Dmitry Samersoff d...@samersoff.net, http://devnull.samersoff.net * I do want to change the world, I don't want the world to change me -- You received this message because you are subscribed to the Google Groups "Trac Development" group. To post to this group, send email to trac-...@googlegroups.com. To unsubscribe from this group, send email to trac-dev+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/trac-dev?hl=en.
